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1.0  SCOPS  OF  THE  INVESTIGATION 

The  motivation  behind  the  research  described  in  this  report  is  to 
enhance  the  digital  designer's  capabilities  by  producing  more  powerful 
design  tools.  Digital  logic  design  has  progressed  to  the  point  that 
the  operation  of  the  logic  can  be  functionally  expressed  by  a variety 
of  hardware  descriptive  languages,  ISP  being  one  of  the  more  widely 
used  ones.  Functional  simulators  exist  and  are  useful  for  verifying 
system  operation  and  performance  measurements  (Barb77a).  Thus,  the 
state  of  the  art  in  digital  design  is  such  that  the  next  addition  to 
design  aids  should  be  synthesis,  a program  that  can  design  the 
STRUCTURE  of  a digital  system,  given  its  FUNCTION  or  BEHAVIOR  as 
input.  Along  with  the  synthesis  of  hardware  comes  the  problem  of 
producing  optimal  or  near  optimal  designs  to  meet  the  design 
constraints.  The  research  reported  on  here  is  aimed  at  understanding 
the  design  or  synthesis  process  so  that  it  can  be  automated.  One  of 
the  goals  of  this  project  is  to  produce  logic-level  hardware  designs 
from  ISP  descriptions  in  a non-optimal  fashion  to  better  understand 
automated  design.  (A  parallel  goal  of  related  research  by  the  same 
group  is  to  develop  discrete  optimization  algorithms  and  technique  to 
be  applied  in  a more  complex  and  powerful  package. 

Unfortunately,  the  area  of  I/O  interface  and  bus  design  is  not  as 
well  organized  or  developed  as  digital  design.  In  order  to  produce 
design  aids  for  this  kind  of  problem,  much  more  background  effort  has 
been  necessary.  First  of  all,  specification  of  bus  and  I/O  operation 
is  a different,  more  difficult  problem  than  logic  description. 


Second,  simulation  is  more  complex  due  to  timing  dependencies  which 
affect  the  logical  operation  of  the  interfaces  to  I/O  and  buses.  So, 
in  order  to  automate  interface  design,  the  remaining  effort  on  this 
grant  has  been  aimed  at  the  problem  of  I/O  interface  and  bus 
description.  The  goal  here  has  been  to  produce  a language  suitable 
for  I/O  description  and  simulation,  with  the  automation  of  complex 
interface  design  a more  distant  goal.  At  the  same  time,  the  synthesis 
programs  described  above  have  been  constructed  so  that  reasonable, 
simple  interfaces  to  the  hardware  being  designed  can  be  specified  and 
included  in  the  design. 

In  the  course  of  pursuing  the  above  goals,  some  other  areas  have 
been  investigated.  These  include  the  specification  of  a module  set 
data  base  for  interface  designs,  the  comparison  of  the  interface 
specification  language  (GLIDE)  with  ISPL,  and  the  description  and 
simulation  of  microcode  execution  for  a number  of  processors.  In  the 
area  of  I/O  design,  some  further  specifications  of  a general-purpose 
programmable  I/O  processor  were  produced,  and  a programmable  FIFO 
buffer  chip  design  was  investigated.  Publications  and  technical 
reports  in  these  areas  are  listed  in  Section  3. 
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2.0  SUMMARY  OF  RESULTS 

We  are  presenting  here  two  main  research  results  - the  GLIDE 
language,  ana  a working  synthesis  program,  the  data-memory  allocator. 
Related  conclusions  and  results  are  also  briefly  enumerated. 

2.1  The  GLIDE  Language 

A summary  of  the  GLIDE  language  progress  is  presented  here. 
Since  the  complete  language  has  not  been  published  elsewhere,  a 
pre-publication  report  is  attached  as  Appendix  I.  The  GLIDE  language 
has  now  been  completely  specified,  and  a compiler  supports  the 
language.  Early  effort  went  into  the  comparison  of  GLIDE  and  ISPL, 
and  this  work  produced  a compiler  which  translated  GLIDE  into  ISPL. 
The  result  of  this  was  a better  understanding  of  the  limitations  of 
ISPL,  and  the  introduction  of  the  PROCESS  concept  in  the  ISPS  language 
and  simulator.  By  PROCESS  we  mean  the  set  of  register-transfer 
operations  which  exist  in  a control  environment  independent  from  the 
control  environment  of  other  operations.  In  addition,  timing 
capabilities  were  added  to  the  ISPS  simulator.  Some  of  the  GLIDE 
control  structures  could  not  be  translated  accurately  into  ISPL,  and 
some  primitive  GLIDE  operations  expanded  into  large  blocks  of  ISPL 
code.  In  particular,  the  GLIDE  memory  constructs  include  FIFO  queues 
and  associative  memories,  which  expand  into  long  routines  when 
translated  to  ISPL.  Also,  the  semantics  of  GLIDE  contain  the  notion 
of  synchronous  data  I/O,  which  cannot  be  described  in  ISPL.  Other 
Primitive  operations  which  translate  to  routines  include  parity  bit 
generation  and  checking,  data  formatting,  and  packing  and  unpacking  of 
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words.  The  major  conclusion  to  be  drawn  from  the  comparison  is  that 
GLIDE  and  ISP  are  different  languages  for  describing  different 
entities,  and  that  the  problems  with  I/O  description  force  the 
existance  of  both  languages  - GLIDE  for  I/O  and  ISP  for  digital 
systems. 

The  maor  output  of  the  GLIDE  effort  so  far  is  two  partial  bus 

descriptions  - the  military  computer  GYK/12  I/O  bus  and  the  PDP-11 
TM 

UNIBUS  . The  UNIBUS  description  is  attached  as  Appendix  II.  Three 
main  conclusions  can  be  drawn  from  these  two  examples.  First,  the 
control  structures  for  nesting  PROCESSES  have  seme  undefined 
semantics,  and  it  is  not  obvious  the  effect  the  PROCESS  priority 
structure  should  have  on  the  execution  of  a GLIDE  program.  Second, 
the  control  structures  inside  processes  are  not  block  structured,  and 
hence  unwieldy.  However,  the  descriptions  seem  to  accurately  reflect 
the  logical  operation  of  the  two  buses,  and  therefore,  the  language  is 
viable  for  bus  and  I/O  description.  (Attempts  to  describe  the  UNI3US 
with  IS PL  and  ISPS  have  not  resulted  in  complete  descriptions) . 
Efforts  are  underway  to  validate  the  GLIDE  UNIBUS  description. 

2.2  Design  Automation 

In  order  to  discuss  the  results  of  the  design  automation  effort, 
an  overview  of  the  RT-CAD  (Register-Transfer  level 
Computer-Aided-Design)  system  is  presnted  here.  This  overview  was 
originally  published  in  (Snow78a) . 
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RT-CAD  OVERVIEW 

The  ulmate  goal  of  the  RT-CAD  project  is  to  provide  a 
technology-relative,  structured-design  aid  to  help  the  hardware 
designer  explore  a larger  number  of  possible  design  implementations. 
Inputs  to  the  system  are  a behavioral  description  of  the  system  to  be 
designed,  an  objective  function  which  specifies  the  user’s 
optimization  criteria,  and  a library  specifying  the  hardware 
components  available  to  the  design  system.  The  components  of  the 
RT-CAD  system  are  shown  in  Figure  1 and  discussed  below. 


I3PS  part*  trip  Optimization  criteria 
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Figure  1:  HT  CAD  System  Overview 
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The  RT-CAD  system  differs  from  other  design  automation  systems  in 
that  it  operates  from  a behavioral  specification.  Such  specification 
provides  a model  that,  while  accurately  characterizing  the 
input-output  behavior  of  a piece  of  hardware,  does  not  necessarily 
reflect  its  internal  structure.  The  design  process  is  one  of  binding 
implementation  decisions  in  a top-down  manner  as  a design  proceeds 
through  the  RT-CAD  system.  More  and  more  structural  detail  is  frozen 
at  each  level  until  a complete  hardware  specification  is  obtained,  the 
most  influential  design  search  space.  The  functions  of  the  design 
system  components  which  bind  these  implementation  decisions  are 
described  below. 

GLOBAL  OPTIMIZER.  The  global  optimizer  applies  high-level 
transformations  to  a design's  behavioral  representation  after 
translating  it  from  ISPS  notation  (Barb77b)  to  an  abstract  design 
representation  called  the  value  trace  (Snow78b) . The  transformations 
have  a significant  impact  on  the  cost,  performance,  and  other 
parameters  of  the  designs  to  which  they  are  applied.  The  research 
described  in  this  paper  centers  around  the  design  representation,  the 
transformations  upon  it,  and  the  strategy  guiding  their  application  in 
the  search  for  an  optimal  implementaion. 

DESIGN  STYLE  SELECTOR.  By  considering  the  various  module  sets 
that  can  be  used  (e.g.,  TTL  vs.  a microprocessor),  the  design 
constraints  imposed  (e.g.,  cost,  speed),  and  the  structure  of  the 
algorithm  to  be  designed  (e.g.,  pipeline  data  flow),  the  design  style 
selector  decides  on  the  specific  style  of  design  to  be  employed  (e.g., 


bit:slice  microprocessor,  MOS  microprocessor,  SSI/MSI  logic).  Earlier 
work  (Thom77b)  shows  this  to  be  an  influential  decision  in  terms  of 
cost  and  speed  tradeoffs.  Whe'.  the  style  is  selected,  the  design  is 
passed  to  an  allocator  specific  to  the  design  style.  Initial  research 
into  the  design  style  selection  process  has  been  completed  (Thom  77a) 
and  an  automatic  design  style  selector  is  currently  being  programmed. 

PARTITIONER.  The  partitioner  groups  operations  from  the  abstract 
design  representation  into  control  steps.  This  effectively  binds  the 
control  flow  for  the  design.  Tradeoffs  between  the  data  and  control 
parts  are  made  at  this  level. 

DATA/MEMORY  (DM)  ALLOCATOR.  The  function  of  the  DM  allocators  is 
to  decide  the  number  and  type  of  data  operators,  rculiplexors , and 
registers  needed  to  implement  the  data  part  of  the  design.  They  are 
style  specific  in  that  they  embody  analytic  and  heuristic  knowledge 
about  a style  (e.g.,  the  trade-offs  involved  in  the  design  of  a TTL 
system) , but  they  do  not  have  access  to  the  specific  details  of  each 
module  set.  The  output  of  the  allocator  is  a data  path  graph  whose 
nodes  are  elements  such  as  adders  or  registers.  An  initial 
implementation  of  an  allocator  for  the  TTL  design  style  is  reported  in 
(Hafe78) . 

CONTROL  ALLOCATOR.  The  control  allocator  generates  a sequential 
state  machine  to  control  the  data  paths  produced  by  the  DM  allocator. 
The  control  allocator  has  the  option  of  designing  the  control  unit 
around  control  philosophies  such  as  microprogramming,  programmed  logic 
arrays,  random  logic,  etc.  The  output  of  the  control  allocator  is  a 


control  path  graph  whose  nodes  represent  control  states. 

MODULE  BINDER.  The  module  binder  selects  physical  modules  from 
the  module  set  library  to  implement  a design's  data  and  control  path 
graphs.  The  library  contains  descriptions  of  the  components  available 
to  the  design  system  and  may  be  freely  updated  so  that  it  is  kept 
current  with  respect  to  advances  in  module  technology.  This  dynamic 
aspect  of  the  module  set  library  provides  for  the  technology-relative 
aspects  of  the  RT-CAD  system. 

PHYSICAL  LAYOUT  PROCESSOR.  This  component  partitions  the  system 
into  printed  circuit  boards  or  chips,  decides  the  placement  of 
components,  routesinterconnecticns,  and  prepares  engineering 
documentation . 

Research  is  currently  underway  into  the  design  of  all  cf  the 
system  components  described  above.  In  addition,  the  problem  cf 
integrating  them  into  a coherent  design  system  is  being  investigated. 

Research  supported  under  this  grant  has  focused  on  the  synthesis 
routines  - the  data-memory  and  control  allocators.  Although  the 
control  allocation  effort  is  just  beginning,  some  ideas  as  to  the 
nature  of  the  problems  to  be  solved  have  been  posed.  The  generation 
of  control  hardware  is  analogous  to  the  problem  of  generation  of 
microcode,  with  its  inherent  computational  complexity,  but  there  is 
one  difference.  Generation  of  hardware  introduces  another  set  of 
variables  into  the  optimization  routines.  Not  only  are 
microinstructions  generated,  but  the  control  hardware  itself  must  be 


designed  and  optimized. 


More  progress  has  been  made  o.i  the  data  memory  allocation 
problem.  A non-optimizing  allocator  has  been  written  and  reported  in 
(ParkYS)  and  (Hafe78).  In  order  not  to  duplicate  these  publications, 
(Hafe78)  is  attached  as  Appendix  III,  and  the  results  are  summarized 
here.  This  allocator  produces  a distributed  logic  design  of  the  data 
paths  and  storage  locations  for  a given  ISPL  description) . (The 
program  uses  ISPL  instead  of  ISPS  because  of  the  ISPS  development 
timetable.  It  is  being  modified  to  accept  ISPS).  It  performs  seme 
error  checking  to  indicate  to  the  user  potential  resource  conflicts 
and  design  errors,  and  functions  independently  of  the  actual 
integrated  circuits  used  to  implement  the  logic  diagram  it  produces. 
Preliminary  checks  indicate  that  the  designs  are  capable  of  performing 
the  functions  present  in  the  original  description.  Two  designs  have 
been  done  by  the  allocator.  The  first  is  part  of  an  elevator 
controller  and  is  described  in  Appendix  III.  The  second  is  the 
PDP-8/E.  A non-optimal  hand  mapping  of  integrated  circuits  onto  the 
allocator  output  logic  diagram  has  been  done,  and  estimate  of  chip 
count  made.  It  is  difficult  to  compare  the  automated  design  with  the 
original  DEC  design  for  three  reasons.  First,  the  ISPL  description 
input  to  the  allocator  declares  as  registers  some  values  the  PDP-8E 
uses  but  never  stores  explicitly  in  registers,  such  as  the  effective 
address.  These  show  up  as  registers  in  the  allocator's  design.  Also, 
the  allocator  designs  distributed  logic,  and  the  DEC  design  was  done 
in  the  central-accumulator  design  style  (For  a discussion  of  design 
styles,  see  (Thom77)).  Finally,  the  DEC  design  has  assumed  a boundary 
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between  the  control  and  data-memory  parts  of  the  design,  but  the 
boundary  is  different  from  that  imposed  on  the  allocator  by  the  ISPL 
description.  Thus  some  tests,  flags,  and  registers  which  must  be 
declared  explicitly  in  the  ISPL  description  are  part  of  the  control  in 
the  DEC  design.  In  spite  of  these  differences,  estimates  of  chip 
count  indicate  that  the  allocator  uses  50$  more  integrated  circuit 
chips  than  the  human  designers  for  the  data  paths  and  registers.  Of 
course,  these  estimates  were  made  using  the  same  1970  technology  chip 
set  the  DEC  designers  had  to  deal  with.  The  50$  excess  hardware  can 
be  found  in  muliplexers  which  connect  the  registers,  the  extra 
registers  declared  in  the  ISPL  description,  and  duplicated  operators 
like  increment,  add,  and  compare.  Much  of  this  can  be  attributed  to 
the  way  in  which  the  ISPL  description  had  to  be  written,  and  seme  of 
these  constraints  will  not  be  present  in  future  ISPS  descriptions. 
However,  other  chips  can  cnly  be  eliminated  when  optimization 
algorithms  operate  at  some  stage  of  the  design  process.  The  complete 
allocator  output  can  be  found  in  Appendix  IV,  along  with  the 
implementation  information  used  to  make  the  chip  count  estimates,  and 
the  PDP-8/E  ISPL  description. 

One  interesting  point  to  be  illustrated  is  the  differences  in  the 
design  seen  even  from  the  block  diagram  level.  This  is  shown  in 
Figure  2.  There  are  two  reasons  for  the  differences.  First,  as 
stated  previously,  the  design  styles  are  different.  Second,  the 
multiplexing  is  used  in  different  ways.  In  the  DEC  version,  the 
operators  are  shared,  and  are  evr  used  to  provide  no-op  paths  from 
one  register  to  another.  In  the  CMU  version,  only  registers  are 
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shared  and  use  multiplexed  inputs.  The  ISPL  language  is  partially  the 
source  of  this  disparity.  In  ISPL,  the  user  can  repeatedly  use 
register  A as  a destination  from  various  sources.  However,  the 
expressions  A+B  and  C+D  do  not  imply  (or  discount)  a single  adder. 
Other  differences  in  the  design  include  the  use  of  multiplexers  for 
shifting  in  the  DEC  design,  and  use  of  true/complement  0/1  chips  for 
creating  complements.  "Oring"  of  the  MQ  and  AC  registers  in  the  DEC 
version  is  done  within  the  multiplexing  hardware.  Constants  are  often 
created  in  one  place  and  gated  over  already  existant  data  paths  to  the 
registers.  In  the  CMU  version,  these  constants  are  multiplexed  at  the 
register  inputs. 

One  final  difference  is  the  treatment  of  the  Link  FF  and 
Accumulator  register  as  a single  register  in  the  CMU  version.  This  is 
done  because  of  the  way  the  PDP-8/E  ISPL  description  was  written. 
Further  analysis  of  this  design  is  in  progress  and  includes  an 
implmentation  of  the  control  by  hand.  Comparisons  of  the  DEC  and  CMU 
speeds  will  then  be  possible. 
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The .0  eve lo p m e nt  of  GLIDE!  a Hardware  Descriptive  Language 
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Thispaper  presents" Glide  » a language  & e i r g n e~d  for  1 / 0 Port 
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allows  description  of  interfaces,  I/O  controllers,  and  buses. 
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Buses,  I/O  transactions  and  Interfaces  can  be  grouped  under  the 
more  general  category  of  ports  and  port  interconnections.  Ports  often 
na  v e~  do  ~be"  s pecif  I ed ' along-  "a  number  o f ~ d i mens  Ion  s - r e 11  a b 1 1 1 1 y 7“ 
performance  and  function  as  well  as  structure.  In  addition,  the 
overall  port  design  philosophy  should  be  evident  from  the 
specif lea t ion . " 


HfttfcQd*  tAX,  EUiA  UiiifiC. 


There”  are  several”  posYIble "ways  to  ^saec ify”  p o r't  "designs”,  'Some" 6 f 
these  verify  that  “ the*  design  meets””  structural  and  functional 
constraints,  and  some  also  demonstrate  that  the  port  itself  Is  capable 
“of  meeting  performance-  reauTre¥ent"s , o~£””i course " f t~is  ”'rnb“re-b  1 f f l’c  u 1 1 

to  demonstrate  that  reliability  requirements  have  been  met. 


Vlrtualiy^all  Implemented  ports  are  specified  with: 

BldcJc  Diagrams  of  interconnections 
, TlmTng”l)Tagra'ms 
~ , ' Verbal  Discussion 
",  Examples 


Certainly,  bloc*  diagrams  convey  some  of  the  interconnection 
structure.  Ideally,  a bloc*  diagram  should  indicate  the  direction  of 

the  transfer  on  the  interconnections , daisy  chaining  and  basic 

functions  of  the  interconnections.  The  IEEE-488  bus,  shown  in  Figure 
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1#  Is  an  example  of  a bloeK  dijigram__speclf lcatlon,  _ 

Timing  diagrams  can  be  used  to  indicate  protocol*  timing 
dependencies*  synchronization  mechanisms*  data  transfer  mechanisms* 
control  of  t he  1 rTter  connect  i ons,  and  priority  allocation  ~ c to  some 
extent).  In  addition,  timing  diagrams  illustrate  the  potential  port 
performance  assuming  the  modules  the  ports  are  attached  to  can  sustain 
the  speeds.  Timing'  diagrams  shbuTd"'be— drawn  “f ronTthe  “v I'ewpb in't“  of 
natfc  communicat  ing  ports  lllce  the  exaimp“le  in"  Figure  ~ 2~,  ~~  The  timing 
diagrams'  can  be  supplemented  with  verbal  discussion*  and  indication  of 
critical- 'timing  dependencies",  “ 

Verbal  discussion  is  most  valuable  when  it  is  used  to  describe 
the  design  phll  osophy,  and  overall  o p e rati  on*  and  to  _s  u pplem  en  t o t he  r 

descriptive  techniques , Figure  3 contains  an ^example  portion  of  a bus 

description  which  presents  a_desigr^  philosophy. 

Exam  pies*  c omple  t e w it  h tl  m'i  rTg  3 i a grams-*  are  6’  f t’e  h us  e d to 
clarify  more ' difficult  joints.  It- Is" extremely  important  that  the 
examples  describe "points  "already  covered  in  "the “specification  and  not 
"introduce  new  cone'eptT,  In  a ddTtlo'n';  examples  should  “6  e"c  1 e a rl  y 
specified"  as  such  and-"any  “bus  'functioning"""  peculiar  to  that  example 
s h o u Id  be'  so  sta ted, 

All  of  these  techniques  provide  a viewpoint  on  the  port  design. 

These  techniques must  be  combined  with  a more  formal  specification 

method  for  a complete  description. 
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Figure  1.  Example  Block  Diagram  (Ricc74) . 
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EoxnaJL  SaadUicatiaa  lacfaaJLaaft*  

Formal  specification*  of  port  and  bus  operation  have  " not  been 
““applied  for  many  “ practical  designs.  However*  some  techniques  do 
~exlTt7  These  arei 

, The ~ st at e d iagr am  approae h 
The  flowchart  approach 
, The  formal "langua g e appToac fi 

Flowcharts _and  state  diagrams  have  been  used  to  describe  a number 

of  bus es  ■ in cludl n g the  _ IEEE -48  8 bus , (See F lgur as  4 and  5 ), 

Languages jiave  been  Slower  to  develop,  

Bell  and  Newell-  (B*1171)  laid  the  groundwork  for  interface 
d es "eriptl  o n ~w ith  their  FequTrements  for  p o rt“d e s crip t lo n In  "the 
Interim”#-  interface  standards  committees  began  struggling  with  the 
description  problem,  Curtis#  working  with  the  Purdue  workshop  on 
~ Indust  r I a i “ Computer  Systems",  i5  ata  Trans  miss  ion  I n ter  f ac  e and 
Committee#  proposed  lbs#  ah  Interface  Description  System  (Curt75), 
The  system  involved  the  use  Of  the  ~~PMS notation#  (from  Bell  and 
— NlFelT)  at  the  top  iev el-#  and  t fi e us e of  a h e w rang u a g e f or 
description  at  the-  “programming  and  register-transf er  levels.  In 
addition#  the  system  “was  to  cover  other  levels  of  description  as  well* 
but  these  were  not  dTf ined  at  the  “time.  The'- hew  “language  ~C“ur t i s 
proposed  was  a version  of  ISP  with  features  of  AHPL  and  with  necessary 
timing  constructs  added,  (Most  of  which  were  being  added  to  the  ISPL 
“ v er  “s  i o n “ o r I S P lew  T* ) , 
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Oevice  is  unaddresaed 
and  ignoring  bus  if  a 

ATN  is  false  

. IFC-MLA-MCOS) 


Device  is  jifdressed 
but  bus  •$  Slid  m 
Command  mode 


IFC 

(within  100  jjs) 


ATN  - Attention 
IFC  - Interlace  Clear 
MIA-  My  Listen  Address 
UNI  - Uniistcn  Command 
ACOS-Accept  Data  Stale 


UNI*  (AC OS) 
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Tj  » Sufficient  time  for  the 
Listener  Function  to  make 
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Figure  5.  Example  State  Diagram  (Rlcc74) , 
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At  thesame  time  Vlssers  had been  developing  a language which  Is 

essentially  a formal  description  of  the  state  diagrams  describing 
Interfacing  functions,  SDLC  and  the  IEEE-488  Interface  bus  have  been 
described  using  this  approach  (Vlss76»  Knob75).  The  formalism  of  this 
language  allows  one  important  application  - functional  simulation, 
Vlssers  has  Intentionally  restricted  the  coverage  of  the  language  to 

the  gate  and  register  transfer  levels#  with  timing  added.  An example 

of the  language  is  shown  In  Figure  6(b)#  which  Illustrates  the  states 

and  transitions  of  an  Interface  device  which  Inputs  an  8 bit  character 
from  an  aysnchronous  serial  line , The  tr ansltlons  depend  upon  the 


input  bits , 


1IIIT:  = Initial  State 

REG:  = Input  1 bit  rag 
Tl:  = Time  between  bi 
COUNT: = Bit  count 


i s ter 
ts 


Figure  6(a)  Interface  Description  Using  the  State  Diagram  Approach 
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V SERXNPUT 


Formal 

Language 


TIT  INITJ  d > oy  I NIT 

[21  COUNT  - 8 

Ell  Pit  DELAY  T 1 

[4]  REG  -e-  I 

t53  COUNT  <*-  ‘ COUNT  ♦ 1 
[6]  -»  (COUNT  A 0)/Pl 


T7T  DELAY  T 1 

[8]  — * (I  a 0)/ERROR  (No  step  bit*) 

Tfl  DELAY  T1 

(10)  — * (I  8 o ) /ERROR  (Only  one  stop  bit) 

tin  — init 


Figure  6TET),  interface  Description  Using  the  State  Diagram  Approach 


There_are^  advantages  and  disadvantages  of  each  of  these 

approaches.  State  diagrams  convey  state  transitions  well,  but 


functions  performed  at  eaeh  state  sometimes  are  obscured.  Even  though 
conditions  for  state  transition  are  specified,  It  is  difficult  to 


a 


extrapolate  from  the  diagrams  to  determine  the  actual  order  in  which 


transitions  occur.  Finally,  the  diagrams  beeome  unwieldy  for  complex 
descriptions. 


— I 


Flowcharts  convey  the  actual  functions  well  but  have  one- 
fundament  aTTimi  tat  ioni  t h ey  are  inherently  sequential.  Parallelisms 
on- the  global  level—[separate  control  environments)  must  be  described 
with  separate  flowcharts , Parallel  Brine Ses  mus t have  special" 
constructs  created7-and  some  things  cannot  be  described  at  all.  The 


elassle  example  Is  a reset  line  which  can  stop  port  functioning  at  any 
"p  oTnt“Tn  J~r eTei-!! T~sTa  t *—var  I abTeT', 


j 


State  diagrams,  flowcharts  and  formal  languages  all  suffer  from 
the  forest-tree  problem.  Unless  the  writer  of  the  description  chooses 


labels  carefully,  documents,  and  structures  his  description,  it  is 
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difficult  for  the  reader  to  ascertain  the  basic  function  being  carried 
out,  A paging  algorithm  for  a each*  memory#  for  example#  must  be 
deduced  from  the  description  and  if  the  variables  are  labeled  "A*# 

■B"#  "C"  Instead  of  ■Higher, bits, PC"#  "Lower , bits. PC"# 'Next .address" 

the  meaning  of  the  description  Is  unclear.  For  any  of  the  above 
techniques  to  be  useful#  a global  flowchart  or  state  diagram  is 

necessary  in order  to  understand  overall  I/O  functioning. Finally# 

the  primitives  of  the  formal  language  must  be  chosen  to^  reflect  the 
primitive  operations  inherent  in  port  anc  l/C  operation.  
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II,  ms  GLIDE  LANGUAGE 

“GLIDE  - a'  Generalized  Language  for  Interface  Description  and 
Evaluation  * is  a relatively  undeveloped  language,  Tetr  it  is  capable 
of  addressThg“some  lssuei~Ieft  untouched”  by  tKe  existing  languages,' 
It  is"  the  only  language  that  is  designed  for  asubset  of  digital 
systems  - interfaces  and  peripheral  controllers!  other  languages 
have  had  a mor e gene ra 1 application,  As  sue h*G Li D E focus e s“on Yom e 
problems  germane  to  Interfacing  and  l/Q, 

Some  s pec iflc  feat ures  o f GLIDE  are  the  f ollowlngi  Values  can  b e 

specified  as  transitions  in  addition  to  level  values^  FIFO  buffers 
can  be  declared  and  accessed  with  single  statements?  Parity  checking 
and  generation  are  primitive  operations  for  GLIDE?  Synchronous  I/O 
and  clocks  can  be  declared,  and  timeout  statements  are  available  to 
the  writer.  Finally*  independent  control  environments  can  be 
synchronously  initiated  under  conditions  declared  in  the  program, 

“This "section  presents  the  origin  of  GLIDE,"  and  section  III  is  an 
introductory  “guide  for“the“use  of  GLlDEV  Discussions  and  conclusions 
in  section  iv  focus  oh  the “appricTtTbhs-  of  "GLIDE , 

aa clear. ouad  a Iht  Qciaio  al  SLIPS  

When  GUI d eTTp  arkT  7a ) was  lntrodu ced,"  1 t was  be se d on- 1 he  p re mTs'e 
that  “digital  1/C  and  “inter facing  functions  can  be  broken  down  into 
four  primitive  groups!  data  storage*  data  manipulation*  control*  and 
^alaT  input/dutputl 
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Given  this  conceptual  partitioning,  the  goal  of  GLIDE  1*  to 

provide  a convenient  descriptive  language  to  specify  the  functions 
within  the  modules  In  a port/  and  between  ports*  For  example*  the 
writer  can  declare  an  external  line  or  group  of  lines » and  bind  them 
to  a direction  like  send/  receive*  or  bl-direetlonal*  and  to  an 
Interface  technology,  A separate  declaration  Is  provided  for 
synchronous  transfers*  Data  can  be  moved  directly  through  the  port  or 


into  an 

Internal 

register 

for  later  manipulation. 

The 

control 

responds 

to  conditions  on  the 

input  lines*  and 

sits 

Idle 

when  no 

startup 

conditions 

exist. 

In  the  same  way* 

eaeh 

of 

the  other 

functional  boxes  shown  above  can  be  described*  The  combined  result^  is 
a complete  functional  description  of  a specific  port,  


Since  normally  GlT D"E  descriptions  are  written  to  pYo  v 1 de 
functi oh  a 1 deser iYt  1 ors*  as  oppos ed  1 6 gate - 1 e v e 1 hardware 
de scrip tions,f he  operators'  provided  “ITT  the  language  comprise  a 
specialized  set  of  operators  SesTghe" r to  maintain  this  TeveT  “o f 
abstraction,*  A typical  GLIDE 'statement  "may  hot  describe  a single 

*These  operators  are_based~bn_a_  set  oY  pYlmYtIWi/a  func  t ion  si  ” ~ 


1. 

Data  Input/Output 

• 

• 

Data  paths  and  data  transfer  mechanisms 

Electrical  characteristics 

, Timing  dependencies  (including  timeouts) 

, Synchronization  mechanisms 

2. 

Control 

• 

» 

Control  of  the  bus 

Priority  allocation 

3. 

Data  Manipulation 

• 

• 

Protocol  (including  interrupts) 

Error  cheeking 

4. 

Data  Storage 

• 

• 

Data  formatting 

Buffering  and  storage 
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register  transfer*  but  rather  a s ingle  digital  function  such  as  buffer 

store*  parity test*  or  data  encode,  A conscious  effort  is  also  made 

to  limit  the  language  to  ports  and  I/O, Therefore  many  functions 

peculiar to _ processors have  not  been  Included  in  the  repertoire  of 

GLIDE  operators.  On  the  other hand*_  a fairly  rich  set  of 

special-purpose  operators  is  provided  to  make  description  writing  more 
convenient, 

a second  major  result  of  the  earlier  work:  is  “ the  embodiment  of 
the  same  s e t o f p r Si itive  d para  tors  i n'a  general  purpose  I/O  processor 
( P io“  rTFaric7  7bT,  S p eelTi  ed  at  the  re  g iTE  er  transf  e r 1“  ev  e r*  Eh  Is“ 
machine  is  designed  to  emulate  any  Plo,  and  it  is  mierocoded  in  GLIDE , 
The  machine  is  modularized*  with  each  module  capable  of  executing  one 
“of  the  orTmitTve  operations  referred  “"to"  “a  b ev  e , T hue- 1 Rej r e“  “are  ~X70 
modules*  “synchronous  “I/O  modules*  parity- check  and  generation  modules* 
and  control  modules*  for- exampler  all  of  which  are  under  GLIDE  program 
control", 

The  generalized  Pio  is  capable  of  Replacing  an  arbitrary  number 

of  Plos  in  a single-comp uter  environment*  This  one  mach i ne_cou l d 

dynamically  reconfigure  itself to_  be  a disk  controller*  teletype 

Interface  (more  than  one  if  desired)*  line  printer  Interface*  magnetic 
tape  unit  controller*  etc.  Its  modularity  allows  its  size  to  depend 
on^  the  number  and  complexity  of  desired  operations*  and  it  could 
easily  be  extended  to  encompass  any  new  device  amply  by  writing  a 
GLIDE  description  and  entering  that  descr iptl^r^  i nto  the  machine* 
inserting  additional  hardware  modules*  if  required.  The  total  number 
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ot  interf aces  which  coul d be  emulted  simultaneously  1»  limited  only  by 
the  speed  and  bandwidth  of  the  machine,  which  has  not  been  determined. 


i 


hi.  a guide  £a&  mz  uaut_ 0£_ slide 

ILa  Exacm  Stmctute 

The  basle  structure  of  a GLIDE  description  la  _the_PROCESS, which 

la  a description  of  an  autonomous  operating  environment  (asynchronous 
control  environment)  along  with  operations  which  take  place  there,  A 

PROCESS consists  of  GLIDE  STRUCTURE  statements,  which  describe  the 

environment  of  operations,  followed  by  PITA  and  CONTROL  SEQUENCING 
statements,  whlch_describe  the  actual  operations,  A PROCESS  may  also 
co nslst  of  local  pro ce s s e s,  whlc h are  s ta r ted _ under  certain  s pecltled 

conditions,  and  remain Idle  whenever  those  conditions  are  not  met. 

The  outermost  process,  o^  the  outermost  block,  is  th^ main  process  and 

contains  all  subprocesses  and  subproeess initiation  conditions 

necessary  to  describe  the  complete  Interface,  An  artlfleal  example 
PROCESS  structure  1^ shown  below  In  Figure  7, 


Here,  the  name  of  the  entire  GLIDE  description  Is  A,  and  there 

are three  subprocesses  AA,  AAAA and_BB, Inside  the  main  PROCESS  A,  a 

pair  of  initiation  staements  sets  up  the  conditions  under  which  AA  and 

BB  are to be^  Started, Any  time  after  these^  statements  have  been 

executed,  as  long  as  A^ls  still  being  executed  and  the  Initiation 
conditions  for  AA  and/or  BB  have  been  met,  either  or  bothpr ocesses 
can  be  started.  If  a priority  ordering  between  processes  Is  desired, 
a priority  for  initiation  can  be  specified  In  the  initiation 
statement.  Once  a process  is  started,  however,  processes  of  higher 
priorities  whose  Initiation  conditions  are  met  ean  suspend  certain 


MAIN  PROCESS  A 


STRUCTURE  statements  - (decimations  \ 
common  to  the  entire  Port  description)  / 


PROCESS  initiation  conditions 
for  AA,  BB 

register  declarations 
interconnection  declarations 
clock  declaration 


\ 


DATA  and  SEQUENCE  CONTROL 
statements  which  operate  in  the  main 
process  environment 


PROCESS  AA 

. STRUCTURE  statements 

(including  initiation  conditions 
for  PROCESS  AAAA) 

. DATA  AND  SEQUENCE  CONTROL 
statements  for  AA 


PROCESS  AAAA 


Bcdv  of  AAAA/ 


END  - end  of  AAAA 
END  - end  of  AA 


PROCESS  BB 


l Body  of  PROCESS 
END  - end  of  BB 


BB 


END  - end  of  A 


Figure  7.  The  GLIDE  PROCESS  Structure 
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lower priority  processes  currently  executing , Of course# the 

Initiation  conditions  can  be  specified  so  that  this  does  not  occur#  as 
will  be  shown  later.  Also#  high  priority  processes  nested  Inside 
lower  priority  processes  will  not  suspend  the  lower  priority  processes 
when  initiated.  Process  AA,  If  higher  priority  than  BB#  can  suspend 
It.  However#  process  AAAA  cannot  suspend  ay  other  process  since  it  Is 

at  the  lowest  level  of  nesting. (In  tact#  AAAA  can  be  Initiated  _only 

while  _AA Is  executing).  The  syntax  of  the  Initiation  statement  is 

Illustrated  with  t hi s example » 

INIT  AAAA » 3 > (ba  AND  be  AND  bd)  a 1 

This  sets  up  the  Initiation  conditions  for  process  aaaa#  wnlch 
has  priority  of  level  3, 

The  process  structure  of  GLIDE  _l _s  designed to  allow  a GLIDE 

description  to  indicate  overall  j>ort  and  bus  operation  to  the  reader. 
Proper  Initiation  conditions  and  nesting  of  PROCESSES  can  provide  an 

accurate representation  of  the  actual  hardware  control  environments. 

The  relationship  between  GLIDE  PROCESSES  and  the  1/0  structure  is 
shown  In  Figure  3#  based  on  our  artificial  example. 


We  new  turn  to  a more  complete  discussion  of  the  GLIDE  language, 

using  parts  of  a UNiBUS-like  structure  as  an  example, 


rrT,tnr  STanming 
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Besides  the  PROCESS  initiation  statements there  are  a set  of 

statements  used  to  declare  aspects  of  the  port  and  interconnect 
structures.  The  first  of  these  to  be  discussed  Is  the  Declaration 
Statement . 


Internal  port  registers  and  port  interconnections  must  be 
declared,  Thesyntax  of  the  declaration  statement  1st 


<fiardware  specT£Tcation>\<name:>,  <name>, , , , , <hame>j 


where  <hardware  specif lcation>  defines  the  logic  type  and 

function 

of  the 

declared  hardware  using  the  following 

abbreviations i 

Basic  logic  typej 

ECL 

TTL 

emitter-coupled  logic 
transistor-transistor  logic 

CMOS 

MOS 

Complementary  MGS' 

Metal  oxide  semiconductor 

TRANS 

transformer  coupled 

Functloni 

CRL 

HIR 

Current  Loop 

High  impedance  receivers 

HLT 

OC 

High  level  transmitters 

Open  collector  gates 

SCH 

TRI 

Schmitt  trigger 

Tri-state 

“TNT 

DIFSVD 

— IntemaT'reglster 

Differential  sender 

SND 

REC 

Sender 

Receiver 

Bl 

DIFREC 

Bl-directlonal 

Differential  receiver 

DIFBI 

<name> 

Dff  f erehtlal~bi -directional 

Is  an  Identifier,  the  first  four  characters  of  which  must  be 

unlgue. 

The  declarations  may  also  have  length  and  width  attached,  as 

in  ISPL 

and  ISPS  (Barb7 8 ) , Some 

examples  of  the  declaration  statement 

arei 
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TT X 0 C Sdata . bus<7  > 0># a d d r es s , bus< 7 1 0 >j 

This  statement  describes  two  8-line  TTL  open  collector  bus 
segments#  one  named  data, bus#  and  one  named  address, bus, 

ECL  INTNcount , reglster<7 1 0> > 

This  statement  describes  a single  8-bit  ECL  logic  register 
which  Is  Internal  to  the  interface, 

T~ function  d'esTg ha tTon  is  mandatory" f 6 r~"eve r’y  d'e claratlon #— but‘a“l ogle 
type”  is  optional , Every”  assignment  bearing  an  INT  functional 
designation  is  considered  to  be  a'register#  and  all  others  are 
Txterna  1~  lines”, 

A seeond_STRUCTURE  statement  is  the  INIT  (Initiate)  Statement 

prevjou s ly  dj scus sed,  it s_synt ax  1st 

INIT  Kprocess  nawe> t <prlor lty>» <varlable>  = <vaiue>i 

<proeess  name> 

is  the  name  of  a process  which  performs a_  _p a r t i c u 1 a r 

, Interface  tasu, 

<varlabie> 

is  the  name  of  the  variable  which  initiates  a proce s s , It 

may  also  be_a^Boolear^and/or  arithmetic  expression  involving 

any  previously^declared  lines#  or  a compound, 

<value> 

is  the  binary  or  octal  value  jof  t^e  variable  which  is  to 

initiate  the  process, 

“ 7 is  a- 0 to  1 tYansTtloh ~o f ””a'”i  Ingle'  bit 

\ Hal  to  0 transition  of  a single  bit” 


<prlorlty> 

is  Che  interrupt  priority  of  the  process. 

Default  is  to  the  lowest  priority  declared, 

EXAMPLE  i 

init  to i ttypei 1 # status*/ 

Process  teletype  is  initiated  when  a line  called  "status”  by  the 
programmer" 'goes  from  0 to  i and  the-  tele type“p r oeess “has  “priority 
level  | (level  o "it  ' tiighoftt  priority),  In  the  unibus 
deter ipti on > the  structure  it  ' bated  on  a bus  arbitration 
mec  h a nisfm , as  s h o w n iiT"F  i'g'u  re~9"i  The  “da  lay  chaTn““  processes  ITT 
the  first  level  of  nesting  allow  bus  request  and  grant  signals  to 
travel  properly  up  and  down  the  UNIBUS,  The  arbitration  process# 
"also  rh  the  first  level"#  has  "nested  w i th  I n Itself  the  "bus 
granting  processes, “The  process"  structure  (Figure  10)  should 
clarify  the  configuration  described, 

FIFO  queues  can  be  declared  with  the  BFR  (buffer  statement)# 

with  this  syntax! 

BFR  <name>  (length]  "<"<wldth>*>" ! 

<name> 

is  the  name  to  be  assigned  to  the  buffer  for  later  program 

use_, 

[length]  

Is  the  number  of  words  In  the  buffer  queue, 

<wldth> 


is  the  bits  in  each  word. 


r 


example  I 

BFR  DISK QUEUE  C4096]<32>  

This  statement  establishes  a butter  ot  length  4096  words* 
each  word  32  b Its  In  length, 

IrTthe  UNIBUS  description*  there  are  two  declaration  types.  For 
example!  " 

0C\MSYN<0>| describes  i single  bit  line  named  "mSyn.» 

The  QC  indicates  open  collector « 

j^YVadat a r e g< iSTo >1  det iheT  a 16  bit  Internal  'ait a 


regl *1  e r named  **adat a r eg , " 


MAIN  PROCESS  UNIBUS 


Declaration!  

Compound  Declaration! 


IN IT  arbittO*  SACK*Vf 

INIT  ndaisychaim 0,  (npra  OR  nprb  OR  nprc 

OR  nprd5»l 

INIT  6daiaychalmO,  Cbr6a  OR  brSb  OR  or 6c 
OR  br6d)*l 

4alsc i JtNITS  tor  priority  level!  A'Af Zi 


PROCESS  ndaiiychaln 


PROCESS  6daisychain 


^PROCESSES  Sdaisyehain#  4daisychain#  7dai!ychain) 

PROCESS  arblt 


INIT  nprgrant Jl rNPRBl f 
INIT  BR4grantt5# (bg, enable  AND  BR4)»lf 
INIT~BR5granti4# (bgtenable  AND  BR5)»1? 
INIT  BR6grant:3* (bg« enable  AND_BR6)» lj 
TNIT  BRTgrantl2T (b  g , e n a ble  AN D BR7)*1> 




• 

t 

END 

• 

• 



END 



— - 

"Tigure  ID,  Process 

structure  of  UNlBUS  Bus  Arbitration  necnanism ■ 
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Code  conversion  Is  often done by  table lookup. (Of  course. 

hardwired  logic  la  alao  uaed  for  thia  purpose  and  can  be  deaerlbed  m 
GLIDE  with  DATA  CONTROL  statements  to  be  introduced  later).  GLIDE  haa 
special  prlmltlvea  for  table  lookup#  after  the  table  has  been  declared 
with  the  table  Instruction,  The  syntax  for  this  1st 

TABL  <name> (length) "<"<wldthl>"><"<wldtb2>*>" 

which  la  uaed  to  set  up  a ta ble  for  code  cony eralo n w h e_n 

conversion  must  be  done  by  table  lookup. 

<widthl>  and  <wldth2>referto  the  bitTwidths  of  the  input 

and  output  w 6 rds  respectively; 

<name>  and  <length>  are  the  same  as  the  Buffer  statement, 

Table  entries  follow  immediately  after  the  table 

declaration#  using  this  format^ 

<encoded^  value>a><decoded  value> 

kencoded  value>  Is  an  input  code  table  entry. 

<decoded  vaiue>  is  anoutput" code  table  entry, 

An  example  of  this  lsi 

TABL  grey  C41k2><2> 

_oo_a>oo 

o l = > o l 

10  oil 

lioior 

"Description  of  synchronous  I/O  is  dlf fTeuTt_Feeause  of  the  differs nt 
"implementations-  oi  hardware  which- perform  synchronization,  GLIDE 


allows  only  a limited  dt«crlptlon  _of synchronous  I/O. Synchronous 

lines  are  declared  with  the  synchronize  statement#  with  syntax i 

SYNC  <name>"<"<lenath>">"»<tlme> 

T h 1 s describes  the  s ynchro nltatlon  mechanism fo r Input ting 

and  outputting  synchronous  data  from  magnetic  tape#  magnetic 
dls)e#  and  synchronous  data  links,  

<name> 

is  the  variable  namedfthe  synchronous  llneCs) * 

<tlme> 

Is jt he  cycl e tl me  in  cl ock  p erlo d Sj, 

<length> 

Is  the  length  of  the  word  sfiTfted’Th  parallel  during  e ach 
synchronous  cycle, 

EXAMPLES;  SYNC  tape  1<8  1 0>9  10000 

describes  the”s y nc h r on o u s transfer  of  9 bits  In 
_ parallel  onto/off  a bus  called  tapel  at  a 
frequency  o'f  10  usee, 

SYNC  disJeaOMOOO 

descrlbTs- 1 he  synchronous  s H iftin g~ o f d ila  oh to  “ “a 
single  Unexcelled  diska#  at  a 900ns  rate. 

The  use  of  synchronous  variables  In  a GLIDE  description  wl l 1 be 


described  later. 


!The  following  declarations  are  compound  expressions.  This  means 
that  there  exists  logic  to  continually  evaluate  the  following 
express i ons ! 

dvaddr ess : =a<0>  AND  a<l>  AND  (NOT  a<2>) ; 

da t i : = (NOT  C0)  ANO  (NOT  Cl)); 

pdat i : = (NOT  Cl)  AND  C0; 

da  to:  = (NOT  CO)  AND  Cl; 

bdato: =C0  AND  Cl; 

p. error; * (NOT  PA)  ANO  PB; 

no.  error  :<•  (NOT  PA)  AND  (NOT  PB) ; 


In  order  to  declare  snchronous  lines,  however,  * clock  must  also 

b«  declared,  me  clock  statement  allows  description  of  a simple 
clock.  The  syntax  lsi 

CLK  <perlod>> 

where  <period>  Is  expressed  In  nanoseconds.  The  default  clock  period 

Is  one  nanosecond,  one  extremely  powerful  statement  used  In 

conjunction  with  Declarations  Is  the  compound  Declaration. This 

Instruction  has  _the^  form_*_  _ 

<name>i=<expresslon>, 

<name>r*<expresslon>,  , , , j 

<name>  is  an  Identifier " and- <expresslon>  is  an  ari thmeTTc 
a ndT" sr  logical  ex  press ion  using  p re v 1 6 u s 1 y ' declared 
variables'.  It  is  continuously  evaluated  and  Is  useful  “for 
describing  combinational  logTe  like  address  rVcogn  rt Ion 
hardware. 

Figure  11  contains  the  C ompound  Declarations  found  In  the  UN IBU3 

description, dvaaddr ess  Is  the  address  of  device  A,  datl,  pdatl,  dato 

and  bdato  refer  to  the  modes  of data  transfer (datl,  datlp,  dato, 

datob)  on  the  bus,  PABB  indicates  parity  error,  and  PABB  indicates  no 
error. 

AllTof  "these  declaration  statements  precede  the  Data  Control  and 
TffoDENCU  CONTROL  statements  ill- the  MAIN  PROCESS  “and- the  subprd'cesses/ 


SEQUENCE  COHIaOL  Etataaiola 
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Many  of  the  sequence  Control  Statements  are  conventional# _ but a 

few  have  features  not  found  In  other  HDL».  These  less-conventional 
ins tru c 1 1 o n s will  be  d e a crlbod  f i rs t , 

The  most  powerful  of  these  Is  the  oe ray- Until  S tatementT 

DLAY  <range>  UNTL  <varlable>a«varlable>  <value>> 

THEN  <b raneh>  ELSE  *error>; 

This  statemeh t <3 elays  the  p r deess  "ex e cution  for  a spec Hie  time  or 
until  a variable  reaches  a given  value  or  equals  another  variable, 

< variable^ 

is"  a variable  named  in  a structure  statement, 

<value> _______ 

Is  a value  expressed  In  "binary#  octal  or  "decimal, 

<braneh> 

Is'^aTprogfam  label  branched  to  if  equality  condition  is  met  in  the 
given  time  period, 

<error>  

Is  a prog  ram  label  branched  to  if  equality  cTndrtTbrTIs- rid  t "m  e tin  the- 
given  time  per iod,  “ 

<ranqe> 

If  a range  of  values  of  time  the  delay" Is  to  last,~ 
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Here 

are  some  simple  uses 

of  the  PLAY  statement!  DLAY  4000; 

This 

statement  delays  the 

Interface  4 usee  (assuming  a ins  clocK), 

PLAY 

UNTL  eheeK*00li 

This 

statement  delays  the 

interface  until  the  variable  checfcaOOl,  and 

PLAY  5000  UNTL  instracodel  then  read  ELSE  wr lte> 

This  statement  delays  the  Interface  Susee  or  until  the  variables  instr 
and  codel  are  equal#  whichever  comes  first.  It  branches  to  *read“  for 
equality  and  »wrlte» If  time  run s o u t j 

This  statemehtis  usef  ul~f  ofdeseribing'  skew  of  lines  and  timeout 
conditional  The  “range  of  delay  times  Is  useful  when  specifying  a 
potential- aus  Tes'Ign" “where- varlaBT'e ~I e hgt fi~ delays- or" timeouts  “need  t o 
be  specified.  The  Delay  Statement  is  used  widely  in- the  example  bus 
description,  For  example inside  the6daisyehain  PROCESS,-  PLAY  UNTL 
B G6«7,  implies  a suspension  of  PROCTSS- ex’ecu tion^unf iT  ~BG6~has  — ah 
upward  transition  “CYymboiized  by- the  forward  slash  "/"),“  Inside  the 
NPR  grant  mechanism  0LAY7S1  is  a~75  "nonosecond  delay  to  allow  for 
signal  skew.  Then,  PLAY  75"0"0T^5W_U NIL- 5 AC  K*  1 j Ihdica tel  that"  The 
PROCESS  suspends  welting  for  SACKto  have  a positive- transition  but 
only" for~5'-i0microse  con  ds depend  ingonThebus  implementation. 


Anot her^ useful^  statement  ii  the  Parallel  Branch  Statement,  used 

to  allow  execution  ^f  multiple  instructions^  at  one  time.  This 
statement  Is  paired  with  the  MRG  emerge)  statements  at  the  end  of  each 


paraiei  branch. 
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PBR  <label>#<label>#,,«  #<labal>i  [FRUN/SYNC3 > 

This  statement  performs  the  following  sections  of  jcode 
referred  to  by  labeljL  either  statement  by  statement 
synchronously  or  on  a free-run  basis, 


FRUN 

signifies  free  run  execution.  Statements  In  each  code 
segment  ~ are  executed  as  icTon  as  ~prevIous_oper  at  ions'  are 
"completed. 


SYNC 


Indicates  that  statement  executions  in  each  code  segment  are 
to  be  synchronized.  In  other  words#  the  nth  statements  In 
all  eode  segments  are  executed  simultaneously. 


Examples i 

_PBR  input#eonvertiFRUN|  ______ 

input  , , « 

•_  • _• 

MRG  J 

convert  , , _* 

• * * 

MRG  | 

This  set  of  statements  causes  the  section  of code  lab eled 

input  to  be  executed  simultaneously  with  the  section  of  code 
labeled  convert,  MRG  Indicates  a merge  at  the  end  of  each 
segment, 


PBR  output # cheeki SYnCj 
>.  tput  s » stement  1 > 
s:atement2f 
MRG  f 

eheeJc  statementl  > 
statement2  j 
MRG  | 
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Thl»  set  of  statements  causes  statements  1 to  be  executed 

simultaneously  and  statements  2 to  be  executed 

simultaneously, 

T wo~  oth  eT- 1 n t e r e s ting  sequene e control  str u c tu  r e s T~  WAIT  and  an  err  of 
branch  associated  with  buffer  accesses  will  be  discussed  later  with 
their  associated  Data  Control  Statements, 

The  other  statements  used  to  control  program  flow  are  liKe  those 
found  In  conventional  microprogramming  languages.  These  ar e i 

e Compare  statement _ 

CMP  <sourcel>«<source2>*a>  <branchl>, a>  <branch2>>_  

Compares  values  of  two  variables or  a variable  and  an 

integer  value  (second  source  field), 

"»><branchl> 

implies  branch  for  a~notTequal  condition,  while 

*>  <branch2> 

means  branch  for  an  equal  condition. 

Here  Is  a simple  examples 

CMP  checici t23‘‘»>  error»a>  otc> 

i Call  subroutine  statement 

CXLL  < subroutine  _label>> 

The  next  statement  executed  will  be  that  labeled,  Control 


is  returned  to  the  statement  following  the  call  statement 
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when  a RETURN  command  Is  encountered  In  the  subroutine, 

• End  subroutine  statment 

RETURN ) 

Endi^a  subroutine  and  returns  control  to  the  calling  site, 
ENDj 

Terminates  a process  description, 

e No  Operation  Statement 

NOPj.  Is  used  primarily  when  two  segments of code  are 

executed  In  parallel  and  are  synchronized, 

e Serial"  Branch  "Statement 

BR  <label>> is  an  absolute  branch, 

• Loop"  Statement 

LOOP<statcment  label >,<repetltlons>> 

— Thla—ata'fen  ent""ex  acute  s'~a'ir~s  tat  ements  through  the  labeled 
Statement  the  spec Ifle  number"  ofTImes,  an  integ a r value 

Example!  

LOOP  done,3> 

<statement  1>|  _ 

donei  <statement  n>t 

ThilTexecute s statements  1 througrTn" three-" time's". 
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• Run  Until  Statement 


RUN  <label>UNTL<varlable>s4<varlable>/<value>> 
THEN  <brancn>> 


This  statement 

is 

similar 

to  the 

loop  statement  but 

terminates  when 

a 

particular  condition  is  reached,  then 

branches  out  of 

the 

program. 

Testing 

is  done  at  the  start 

o f each  loop.  If  THEN  <branch>  Is  omitted/  execution  picks 
up  at” the  first  statement  after  the"  loop. 


Example  t 

RUN  proel  UNTIi  varV*var4  then  inter rupt  i 


• I • 

Proel i . , ",  End  of  loop 


Tnt erruptl  New  code  segment  begins- her" s, 

e Set  statement  

Set  <labeT>7 

"This  " set  s an  Intel  rupt  1 1 n e "f  r o m the"' interface.  The 
1 nt erru  p t"ll he~may  "be  any  "declared  external  "variable, 

e Reset  Statement 

RSET  <label>r 

TfiTs- r esetsan  Interrupt  line-; 


J 
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The  example  bus  description  uses  Jh^  compare  statement in the  daisy 

chain  processes,  JIMP  br6ail  =>  done;  causes  control  to  go  to  the 
"done"  labeU If_not#  control  flow  continues  to  the  next  statement, 

Cont r o l~hor  ma  1 1 y~~ flows'! rom  statement  to-  statement/' ' with  the 
delimeter  between 'statemants  being  a semieolon.  If  two  statements  are 
to  be  executed  In  the  same  clock  period/  however#  the  ; delimeter  can 
be  replaced"  with- ALSO'  For  e"xamp IT 
'A«-l  ALSO  B<-  1 » 

causes  A and  B to  be  set  to  1 then  C to  be  set  to  0, 
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I 


1HE  BAIA  COUTROL  TN*TP_Uf"TTnM* 


With  one  exception,  the  DATA  CONTROL  statements  all  have  the  same 
structural 

<de st!natTon><-< source “expression* 

<destlnation> 

is  any  name  bound  to  a hardware  structure  Cl.e,,  external 
lTne s#  InTernai  re 9 1 it er s»  buff ers#  synchronous  line s7 
etc.) . “ 

<source  expression> 

is  a variable,  value,  compound,  arithmetic  and/or  logical 

express i on or an ex p r «»1  on  uii ng  th ^operators  described 

below , 


Arithmetic  operators! 


♦ 

addition 

m 

subtraction 

# 

multiplication 

/ 

division 

Logical 

operators  t 

AND 

logical  and  of  both  operands 

OR 

logical  or  of  both  operands 

XOR 

logical  exlusive  or  of  two  operands 

NOT 

logically  complements  source  and  places  in 

destination 


; ! 1 
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The  logical  operator!  are  used  widely  In  the  COMPOUND # PLAY  and 

INit  statements.  For  an  examp ie_  se_e_ Figure  il_  which  contains  compound 
expressions  from  the^bus  example.  The  INIT  statement  uses  logical 
operators  widely,  as  in  thl s statement  from  the  UNIBUS  description! 

INIT  6daisy  chain! 0# (br6a  OR  br6b  OR  br6c  OR  br6d)*i f 

Of  course,  the  simple  source-destination  transfer  is  widely  used 

in  the  example. BR6-<— 1>  is  one  Instance  of  this, 

there  are  seven  primitive  I/O  operations.  The  first  two  are 
Encode-  and'  Decode”, 

ENC  t<table>] 1 1 

Encode  from  binary  using  the  table  specified.  This  operator  returns  _0 

It  the  value  canot  be  encoded.  Choices  of  tables  are  UNARY#  GREY# 
HAMMING  and  DISTANCE  3, 

DC  0”~[ :<tabl  e >11 

Decode  into  binary  using  the  table  specified#  returning  0 if  not 
deeodableV 

It  should  be  noted  here  that  other  encodlng/deeodlng  problems  have  to 
be  declared  explicitly  usng  the  TABL  declaration.  Here  is  an  example 
of  both  methods! 

TABL  grey 1 43  <2><2> 

00  00 
01  01 
10  11 
n roi 

This  table  is  accessed  by  the  statement!' 
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<d  s s tin  at  1 on  > <tab  le  name  ><  s eure  e > j 

or  for  this  instance: 

Cl)  A<1  iO>«-  grey'lOj 

and  the  value  in  A a 11  at  the  end  of  execution, 

C 2 ) A<1 10>«— ENC  [grey]  'io» 


Is  an  equivalent  statement.  The  inverse  of  this  statement 


1st 

A<1 1 0>-^-DEC  [grey]  '11 ; 

and  the  value  returned  is  10, 

Besldesthe  eneodlhgdatafunction*  formatting#  packing  and  error 
checking*  are  important  “funetibns'per formed  by  ports  and  interfaces. 
Formatting"  carT  be  as  simple  a s~  con  catenation  or  as  complex  as  “"the" 
"intermixing  of  two  operandsin  a random  pattern , The  Format  Statement 
(FMT 1 provides  a general  mechanism  for  thisT 

FMT  <sourcel>  C<pattern>]  <source2>^ 
where  <source 1>  and<sourc«2>  areoper ands  or  values  and  <patterh>  is 
^pattern  of  #and/,  An  #indlcatesa  bittaken  from  sourcel  and  a / 
Indicates  a bit  from  source2"i  The  absence  of  a pat" tern"  implies 
concatenat ion.  For  examp ie  i 

ak? l Ox— FMT  ' 00 0 or#/#/*'*/]  'ill  17 
Teiurns- the~vaTue  'OlOldOTi  f'  lndica  tes  a “binary  v aTue  3'«~~ 

Packing  and  unpacking  bit  slices  from  words  is  less  complex*  and 
the  Paek  (PAC)  and  Unpack  (UNPAC)  statements  provides  for  this. 


PAC(<variable>)  packs  a bit  slice  into  the  position  in  the  word 


specified  by  the  < variable^,  UNPAC (<varlable>)  return!  the  slice  from 

the  word.  Tor  Instance i _ 

A<3|0>^-  PAC ( 1 )B<1 1 0>y 

places  the  B_b Its  Into  the  lowest  orde r C 1 and  0 ) bits  of  A , 

A<3  |0><-  UNPAC(2  ) B<1 5 : 0>  f 

places  valuesfrom  B<7|4>  Into  A, 

Par ity  but  generation  and  checking  Is  don#  with  a ret  * of 
st at ements , the  ' T est “an d Pa r it y sat e m eh ts . 

PARE  <source>  generates  an  even  Parity bit and PARC  __<souree> 

generates  an  odd  parity  fc>lt, TSTE  <souree>  and  TSTO  <source>  perforin 

a parity  check  and  return  a *f  parity  is  valid,  a 0 if  there  is  a 
parity  err or. 

“The-  la¥t  two-  state  went  s t o'"  be  prefentedconcern  synchronous  data 
transfer  and“  buffer  accesses.  Since  the “variables  permitted  in  GLOE 
statements  may  be  one"  of  several  2TTf er eht  types,  s ome  comments 
concernlngthe“useof  each  type  should  make  their  intent  clearer, 

Use  of  a variable  declared  in  a bfr  statement  carrier  with  it an 

implicit  buffer memory access , Tjie  total  number  of  items  stored  in 

the  buffer  may  not_e3<®eed  the  declared  ^lze,  if  it  does#  an  error 

signal  will  be  generated, and  the  most  recent  store  will  not  be 

completed.  The  error  will  be  detected  if  statement  label  is 
attached  to  the  buffer  name  in  the  execution  statement  with  a "I", 

For  example,  in  the  statement  FlFCMbf rful-*-A<7 >0>>  if  Fir 0 is  a 

declared  buffer  memory  and  execution  of  this  statement  causes  it  to 
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overflow,  the  next  statement  to  be executed  will  be "bfrf ul . " The 

default  error  branch  also  applies  to  buffer  accesses  when  an  empty 
condition  occurs,  A ■* — FIFQiBfreptyj 


Use  of  a variable^  e e la  red"  in  a “sync  st  at  e m e ht  “carr  i eaf“w  i t h“i  t “an 
implicit  synchronous  transfer  of  the  data.  For  a parallel  tranfer, 
the  word  length  of  both  source  and  destination  must  match  the 
synchronous  Varl able  Ten  gth,  For  sari aTtran  s fer , the  sync hr oho  us 
variable  is  always  of  length  i,  to  the  other- varlab 1 e may  be  of  any 
length  gr eater  than  e r egua 1 to  1,  ~ For  the  parallel “case , “theme  an  ing 
o t “the  "transfer  is  e'learl  for  the  s erlal  ca  se  “the- translfer-  me  a n s~th  a t 
a sh if t t aice I p lace  at  t h e f r equency “s  p eeified  (w it h ”n o extra  delay 
when“^he“  shift  “register  is“  loaded  with  a“new  word  “or  emptied).  If  a 
delay  is  desired  “it"  may-  be  achieved  “b  y us  in  g“  thT“D  L AY“«  t a tement, 

Immediately afjter  a synchronous  variable  ij  aceessed/stored  into 

a shift  register#  a WAIT  statement  must  be  used  to  allow  time  for  the 
data  to  be  synchronously  input.  Here  is  a brief  example,  


j] 

In  thed *” s iarations  we  f i hd  i 

5 YNU“d  rs)T“<“0  2001 

which  means  we“have  "a  synchronous  line  baled-  disk-  which 
It  us  talhs“a“  data  rate  of  1'  b it  every"200  s , 

In  the  body  we  find!  

LOOP  done,  32) 


A<3 1>  ■*-  dls)C| 

— A/2 > ishift  right  A 
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iju_,  cnacLusuiMs  m nisrusfiinM 

GLIDE  has  grown  from  a microprogramming  language  for  a 
general-purpose  I/O  processor  to  a descriptive  language  for  I/0» 
interfaces  andbuses,  while- no  apologles  are  made  for  thesyntacticai 
artifacts  of  the  micro-language*  we  should  stress  that  GLIDE  is 
evolving  and  continually  changing.  It  has  proved  itself  adequate  for 


the  UNIeTO'S  descriptive  taslc,  a non-trivi'al  problem 

, A comp  Her" 

exists*  and  a simulator  is  being  written. 

The  simulator  will  allow  research  to  proceed  In 

studying  bus 

structures*  I/O*  and  multiprocessor  communications. 

It  will  also 

provide  a tool  for  teaching  the  above  In  an  Interactive 

fashion. 
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!This  is  a partial  description  of  the  UNIBUS  operation.  In  order  to 
make  the  description  complete,  the  daisy  chain  bus  request  and 
grant  signals  are  included,  but  only  specified  for  four  devices  for 
each  level  of  priority,  devices  A,B,C.  and  0,  where  A is  electrically 
closest  to  the  processor. 

A GLIDE  description  contains  a main  PROCESS  and  as  many  nested  sub- 
processes as  possible  to  describe  a set  of  interfaces  connected  together. 
In  each  PROCESS,  including  the  main  one,  there  are  declarations 
which  define  the  structure  of  the  interfaces,  and  sequence  statements 
which  describe  the  operations.! 

MAIN  PROCESS  UN I BUS 


!Here  we  have  declared  the  main  process! 
! S i gna I I i nes ! 


(address  lines, open  collector! 
!Data  lines,  open  collector! 
(control  bit! 

! contra  I bit! 

(master  sync  line! 


sync 
i ne ! 
i ne ! 


! s I ave  sync  I i ne ! 
! par i ty 
!par i ty 

! i nterrupt  I i ne ! 

! bus  request  I i ne, 
! bus  request  I i ne. 


priori ty 
pr i or i ty 


l eve  l 
I eve  I 


OC\a<17:0>; 

OC\O<15:0>: 

OC\C0<0>; 

0C\C1<1>; 

OC\t1SYN<0>; 

OC\3SYN<0>; 

OC\PA<0> ; 

OC\PB<0>: 

OC\INTR<0>; 

QC\BR4<0>; 

OC\BR5<0>; 

OC\BR6<0>; 

OC\BR7<0>; 

OC\BG4<0>; 

OC\BG5<0>; 

OC\BG6<0>; 

OC\8G7<0>; 

OC\NPR<0>;  (non  processor  request  line! 

OC\NPG<0>;  !non  processor  grant  line! 

OC\SACK<0>;  (selection  acknowledge! 
OC\BBSY<0>;  !bus  busy! 

0C\bg. enab I e<0>;  !bus  grant  enable  (set/reset 
INT\ i nterrupt . vector<15:  0>;  (interrupt  vector 
I NT\s I ave. address<15: 0>j 


4! 

5! 


!bus. grant  line,  priority  level  4! 


by  processor)  ! 
internal  to  device! 
islave  address  used  by  device  B for  NPR ! 


!The  following  lines  make  up  the  daisy  chain  bus  request  and  grant 
mechanisms.  Each  part  of  the  chain  is  specified  as  a separate 
line  for  ease  of  description! 


OC\br6a<0> 

OC\brGb<0> 

OC\br6c<0> 

OC\br6d<0> 

OC\bg6a<0> 

OC\bg6b<0> 

OC\bgEc<0> 

GC\bg6d<0> 

OC\npra<0> 


line  from  the  devA  to  the  grant  mechanism! 
line  from  the  devB  to  devA! 
line  from  devC  to  devB! 
line  from  devD  to  devC ! 

(grant  line  from  grant  mechanism  to  devA! 
(grant  line  from  devA  to  devB! 


!The  same  for  nonprocessor  request  and  grant  lines! 


OC\nprb<0>; 

0C\nprc<8> ; 

OC\nprd<0>: 

OC\npga<0>; 

OC\npgb<0>i 

OC\npgc<0>; 

OC\npgd<0>; 

I NT\ada tareg<15: 0>;  !data  reqister  in  device  A! 

I NT\bdatareg<15: 0>;  (data  register  in  device  B! 

(The  following  declarations  are  compound  expressions.  This  means 
that  there  exists  logic  to  continually  evaluate  the  following 
express i ons ! 

dvaddress:  =a<0>  AND  a<l>  AND  (NOT  a<2>); 

dat  i : = (NOT  C0)  AND  (NOT  Cl)); 

pdat i : = (NOT  Cl)  AND  C0; 

da  to;  = (NOT  C0)  AND  Cl; 

bdato: =C0  AND  Cl ; 

p. error := (NOT  PA)  AND  PB; 

no.  error:  = (NOT  PA)  AND  (NOT  PB) ; 

(Now  come  a series  of  initiation  conditions  for  various 
"processes".  These  are  declared  now,  but  the  processes  are 
initiated  whenever  the  conditions  become  true,  and  the  process 
has  higher  priority  than  any  other  process  uhich  also  has  met 
its  initiation  conditions! 

I N I T arb i t : 0, SACK=\; 

! the  above  statement  initiates  the  arbit  process  ui th  0 priority, 
whenever  the  SACK  line  has  a negative  transition! 

INIT  dvaslo.ve:0,  (BBSY=/  AND  DVADDRESS)  * 1; 

(Device  A is  initiated  as  a slave  when  bus  busy  is  asserted  high, 
and  the  device  address  has  been  decoded! 

INIT  Gdai  sychain:0,  (brSa  OR  brGb  OR  brSc  OR  brSd)-l; 

!6daisy  chain  is  the  daisy  chain  mechanism  for  priority  level  G! 

INIT  nda  i sycha i n; 0,  (npra  OR  nprb  OR  nprc  OR  nprd)=l; 

(this  is  the  daisy  chain  mechanism  for  the  NPR  requests! 

'.There  are  similar  processes  for  the  other  priority  levels! 

PROCESS  6dai sycha in 

BR6«-/;  !Send  the  bus  request  through! 

OLAY  UNTL  BG6=/;  !Uait  until  the  grant  signal  comes  back! 
bgGa*-/;  (device  A,  closest  to  the  processor,  gets  the  grant! 
CMP  br6a:l  =>  done; 

(compare  bus  request  from  dev.  A to  1.  If  equal,  then  you  are 
done.  Otherwise,  pass  it  on! 
bgGb*-/; 
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CMP  br6b;l  =■>  done; 
bg6c«-/; 

CMP  br6c:l  =>  done; 
bg6d*-/; 

done:  end;  lend  Gdaisy  chain! 

PROCESS  ndaisychain 
NPR  - /; 

OLAY  UNTL  NPG  - /; 
npga  «-  / ; 

CflP  npra:l  =>  quit; 
npgb  «-  /; 

CMP  nprb:l  =>  quit; 
npgc  «-  /; 

CUP  nprc: 1 ■*>  quit; 
npgd  «-  /; 

quit:  end;  lend  daisy  chain  for  NPR! 

PROCESS  arbit 

IN1T  npr. grant: 1, NPR-/; 

INIT  BR4. grant : 5, (bg. enab I e AND  BR4)=1; 

INIT  BRS. gr ant : 4 , (bg. enab I e AND  BRS)=1; 

INIT  BRG. grant : 3, (bg. enab I e AND  BRG) =1 ; 

INIT  BR7. grant : 2,  (bg. enab I e AND  BR7)=1; 

IThese  grant  mechanisms  are  initiated  in  a priority  order! 

!For  simpl  ici  ty.only  the  priority  level  4 and  NPR  levels  will 
be  shown! 

DLAY  UNTL  (NPR  OR  ( (BR4  OR  BR5  OR  BRG  OR  BR7) AND  bg. enab I e) ) «1 
!As  soon  as  one  of  the  lines  is  raised,  the  PROCESS  ends, to 
prevent  any  other  PROCESS  from  now  being  started.  Otherwise, 
a higher  priority  PROCESS  could  be  started! 

END;  !End  of  process  arbit! 

PROCESS  npr. grant 
DLAY  75; 

NPG  - /; 

OLAY  7500+-2S00  UNTL  SACK  . /; 

NPG  - \; 

END; 

PROCESS  br4. grant 
OLAY  75; 

BG4  - /; 

DLAY  7500+-2S00  UNTL  SACK  = /; 

BG4  - \; 

END; 

PROCESS  dvamaster 

!This  process  describes  the  sequence  device  A goes  through  to 
interrupt  the  processor! 

(This  device  is  capable  of  bus  mastership  and  has  priority  level 
G.  It  i 8 wired  closest  to  the  processor  of  all  priority  level  G 


A 
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!The  device  requests  bus  mastership  by  raising  its  bus  request  line! 

!This  causes  the  daisy  chain  for  priority  level  G to  be  initiated 
and  subsequently  causes  the  arbitration  and  granting  mechanisms  to 
be  initiated! 

DLAY  UNTL  bgGa  = /; 

!Uait  for  the  bus  grant! 

SACK  - /; 

! Acknow I edge  the  bus  grant! 

PBR  one, two:  FRUN 

! T h i s construct,  the  parallel  branch(PBR),  forces  execution  of 
code  segments  labeled  "one"  and  "two"  to  be  done  at  the  same  time, 
but  not  in  I ockstep (FRUN  signifies  this)! 

one:  DLAY  UNTL  BBSY  = \; 

BBSY  /; 

!Wait  until  the  bus  is  no  longer  busy,  then  make  it  busy! 

D<15:0>  «-  i nterrupt.  vector 
DLAY  UNTL  SSYN  = 0; 

I NTR  «-  /; 

DLAY  UNTL  SSYN  = /; 

D<15:0>  «-  0; 

I NTR  - \ j 

!SSYN  and  INTR  are  handshake  lines! 

BBSY  «-  \ ; 


OLAY  UNTL  npgb  - / ; 

!Uait  for  the  bus  grant! 
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SACK  - /; 
nprb  <-  \; 

□LAY  UNTL  BBSY  - \; 

BBSY  - /; 

!Uait  until  the  bus  is  not  busy  then  get  it! 

A<17:0>  ♦-  s I ave.  address; 

C0  «-  0 ALSO 

Cl  «-  0;  ! Th i s is  the  code  for  DATI  ! 


! OAT  IP  is  similar  except  the  C0  and  Cl  code  is  different! 


DLAY  150; 

OLAY  UNTL  SSYN  - 0: 

NSYN  <-  \; 

DLAY  10000  UNTL  SSYN  - /; 
bdatareg  d<15:0>; 
hSYN  - \; 

OLAY  75; 

A<17:0>  ♦-  0; 

C0  - 0; 

Cl  «-  0; 

BBSY  - \; 

END; 

!End  of  device  B OATI , (PROCESS  devbmaster) 

!For  DATIP,  BBSY  uould  have  stayed  asserted,  then  the  output 
cycle  would  have  begun  just  as  in  DATO  or  DATOB! 

PROCESS  dvaslave 

! Th  i s describes  how  device  A responds  as  a slave  device  to  DATI, 
DATIP,  DATO,  and  DATOB! 

DLAY  UNTL  HSYN  = /; 

CNP  DATI : 1 =>  in; 

! I f OATI  -1,  the  master  wants  to  input  data,  go  to  "in"! 

CNP  PDATIsl  =>  in; 

!This  is  the  same  as  DATI  from  the  point  of  view  of  the  slave! 

CNP  DAT0:1  =>  outword; 

INaster  wants  to  output  data  to  slave! 
outbyte:  CNP  A<0>:0  =>higher; 

lower:  adatareg<7: 0>«-O<7: 0>;  !get  lower  order  byte! 

SSYN  - /; 

DLAY  UNTL  NSYN  - \; 

BR  fin i sh ; 

!Go  to  the  finish! 

higher:  adatareg<15:8>*-d<15:8>;  (Input  higher  order  byte! 


! NOTE  - in  reality  the  adataregi ster  is  only  8 bits  long  when 
bytes  are  transferred.  It  was  described  this  way,  so  that  both 
word  and  byte  I/O  could  be  covered! 


outword: 

i n: 

f i n i sh: 
END 


SSYN  - /; 

OLAY  UNTL  HSYN  - \; 
BR  fin i sh ; 
adatareg  <-  D<15: 0>; 

SSYN  - /; 

DLAY  UNTL  MSYN  = \; 

BR  fin! feh ; 

0<15: 0>  <-  adatareg; 

SSYN  - /; 

DLAY  UNTL  MSYN  - \; 
D<15:0>  «■  0; 

SSYN  «-  \; 

END; 


! Th  i s ends  the  UNI  BUS  description  as  far  as  it  is  implemented! 
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ABSIRACJ 

This  paper  presents  a portion  of  the  register-transfer  level 
computer  aided  design  (RT-CAD)  research  at  Carnegie-Mellon 
University.  This  part  of  the  research  involves  the  design  and 
construction  of  an  allocator,  consisting  of  a set  of  algorithms  and 
data  structures  which  synthesize  hardware  at  the  logical  level 
from  a behavioral  description.  Preliminary  results  indicate  the 
allocators  performance  compares  favorably  with  a human 
designer. 


I Introduction 

The  research  described  in  this  paper  represents  a portion  of 
the  overall  Register- Transfer  Level  Computer  Aided  Design  (RT- 
CAD)  effort  at  Carnegie-Mcllon  University.  This  is  a continuing 
research  protect  which  grew  out  of  an  initial  design  automat  ton 
system  reported  in  [Oaroacci  75],  The  present  system  differs 
from  conventional  CAD  systems  in  that  the  input  to  the  system  ts 
a behavioral  description  of  the  hardware  to  be  designed.  Modules 
in  the  system  include  a compiler  for  the  input  hardware 
descriptive  language,  ISPl,  and  a simulator  Currently  under 
construction  is  a module  which  selects  the  design  style  for  the 
logic  to  be  constructed  [Thomas  77],  Manipulation  of  a data 
structure  derived  from  the  input  description  in  order  to  optimize 
price/performance  constraints  has  been  investigated  by  (Snow 
78]  The  allocator  routines,  which  occur  after  this  manipulation, 
output  a logical  design  which  is  transformed  by  the  data-base 
module  mlo  integrated  circuit  chips  and  interconnections.  All  of 
the  modules,  with  Ihr  exception  of  the  data-base,  cither  function 
independently  of  or  lelabve  to  the  contents  of  the  data  base 
module  sets  One  of  I he  allocation  routines,  the  distributed  logic 
allocator,  is  the  subject  of  this  paper.  A more  detailed  overview 
of  the  system  can  he  found  in  [Snow  78]. 


II  Allocator  Overview 

After  the  algorithmic  description  (ISPL)  of  the  system  to  be 
designed  has  been  manipulated  by  the  higher  level  design 
routines  to  achieve  the  pnee/per formance  objectives  provided 
hy  the  urrr,  it  ir.  used  as  input  to  the  allocation  routines.  The 
allocators  fall  into  two  categories,  data-memory  and  control.  The 
data-memory  allocators  perform  a mapping  function  from  the 
algorithmic  description  to  the  data  part  of  the  hardware 
implementation.  The  data  part  is  considered  to  consist  of  the  data 
storage  elements,  data  operators,  and  data  paths  (including 

The  research  described  in  this  paoer  was  supported  in  part 
by  the  US.  Army  Research  Office  under  grant  « DAAG29-76-G- 
0224 


multiplexers  and  dcmulliplexers)  necessary  to  implement  the 
operations  specified  m the  algorithmic  description.  It  should  be 
noted  that  due  to  the  char acleristics  of  the  ISPL  language,  this 
mapping  may  bo  or.e-fo-many  or  many-to-one,  rather  than  a 
Simple  one-lo-one  translation.  The  control  allocators  perform  a 
slightly  different  funchon.maoping  the  timing,  sequencing,  and 
branching  information  implicit  in  the  ISPL  description  onto  control 
states,  control  signals,  and  condibonaf  branching  signals  to 
control  Ihe  data  part  Again,  the  mapping  is  not  a simple  one. 

The  allocator  described  here  is  a data-memory  allocator  for 
the  distributed  logic  design  style.  As  we  pointed  out  earlier,  the 
allocator  it-. ell  is  technology  independent,  and  the  mapping  of 
data  operations  onto  specific  integrated  circuit  packages  is 
performed  hy  the  data  base  module.  The  data-base  module  can 
be  updated  as  new  packages  are  added  lo  the  module  sets.  It 
should  he  understood  that  the  process  referred  to  as  allocation 
throughout  the  remainder  of  this  paper  is  a logical  allocation  in 
terms  of  a generic  set  of  data  storage  elements,  operator 
primilives  defined  by  Ihe  ISPL  language,  data  paths,  and  the 
abstract  switching  functions  multiplex  and  demultiplex. 

The  first  version  of  the  allocator  is  experimental,  and  it 
performs  oniy  minor  optimizations  on  the  designed  hardware. 
Rather,  it  has  been  designed  to  illustrate  : 

t The  feasibility  of  hardware  synthesis  from  an  ISPL 
description 

* The  independence  of  Ihe  allocator  from  specific  integrated 
circuit  module  set  information 

t Information  necessary  to  the  design  process  which  cannot 
be  expressed  in  ISPl 

* The  types  of  data  structures  needed  for  the  allocation 

* Bounds  on  Ihe  size  of  Ihe  ISPL  input  description  that  can 
be  processed  by  the  system 

* Exceptional  constructs  possible  in  ISPL  which  may  be 
difficult  or  impossible  to  design  or  implement  in  hardware 

t Types  of  error  checking  that  can  be  performed  by  the 
allocator 

* Areas  where  optimizations  are  possible  in  future,  more 
sophisticated  aflocafors 

In  addition,  the  allocator  has  been  designed  as  a possible  skeletal 
structure  for  future  allocators  in  order  to  ease  the  programming 
overhead  and  standardize  input/output  formats  and  data 
structures. 

In  the  following  cfescripfion  of  allocator  structure  and 
function,  we  attempt  lo  extrapolate  details  learned  through 
implementation  into  a basic  philosphy  of  allocator  design  The 
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procedure  prod  by  the  allocator  might  be  compared  to  a two 
p,r.s  compilation.  The  lire- 1 pass  may  be  considered  as  a syntax 
and  feasibility  check  The  allocator  inputs  a parsed  ISPL 
description,  constructs  data  structures  analogous  in  function  to 
symbol  tables,  and  enforces  various  constraints  necessary  to 
insure  that  the  data  -lor age  locations,  logical  mappings,  and 
•nput/output  interlace  c harar  (eristics  specified  in  the  description 
can  be  implemented  in  hardware.  If  no  errors  are  encountered,  it 
proceeds  to  allocate  Ibe  basic  data  storage  structures  called  for 
in  the  description,  and  any  additional  data  paths,  storage,  and 
operators  necessary  to  implement  variable  accessing  schemes 
described  by  the  logical  mapping  facility  of  ISPL  The  second  pass 
may  be  considered  as  the  semantic  phase  with  the  activity  of 
code  generation  replaced  by  the  allocation  of  data  paths, 
Operators,  and  additional  -jiorage  as  needed  to  implement  the 
functions  specified  in  the  ISPL  description  Parallelism  analysis  is 
performed  at  several  levels  to  warn  the  user  of  error  conditions 
(array  acess  conflicts;  variable  value  ambiguity  due  to  parallel 
assignmonl/iee)  and  determine  constraints  relating  to 
optimization  of  the  hardware  The  allocation  is  then  completed  by 
the  addition  ol  multiplexing  where  necessary 

Allocation  differs  from  compilation,  however,  in  that  in  a 
compilation  one  is  concerned  with  implementing  the  specified  data 
operations  on  a fixed  data  pari  whose  capabilities  are  known  a 
priori.  In  allocation,  the  allocator  must  he  able  to  recall  and 
uhlize  the  capabilities  ol  a data  part  which  is  beng  dynamically 
created.  The  allocator  thus  works  from  the  inside  out,  first 
creating  the  data  •■Inrage  .uvl  arc*-**  'true  hires,  and  then  adding 
the  norns' ary  data  path'  and  operator'  to  perform  the  desired 
data  operations  In  .idrlilion,  the  output  of  the  allocator  is,  in  the 
general  ca'o,  .1  non  planar  directed  graph,  ralhor  than  a linear 
list  of  compiled  instrui  lions 

The  central  concept  used  in  the  alloc  alien  process  is  the 
operation  path  In  tlv  most  general  (a'f,  Ibis  consists  of  two 
sources,  an  operator,  and  the  data  paths  from  each  rOucce  to  the 
operator  fins  concept  was  chosen  as  ti»p  base  because  Hie 
Operation  path  if  the  minimal  uivl  winch  can  be  considered  when 
analyzing  for  prvribe  parallelism  conflicts  during  optimization  to 
reduce  llm  number  of  allocated  operators.  Throughout  the 
following  allocation  dr- c r»pbon,  the  term  path  will  mean  operation 
path,  while  the  pi  iy*  real  dala  path  between  a source  and  a 
destination  will  he*  1 ••hired  to  as  a link. 

The  detailed  de'rnphon  of  the  allocator  will  focus  on  the 
allocator  inputs,  ifata  structure'',,  algorithms,  and  Outputs. 


Ill  Allocator  Inputs 

The  primary  input  is  the  compiled  ISPL  description,  in  the 
form  of  a symbol  table  and  a statement  table.  This  input  is 
augmented  with  information  supplied  by  the  user  in  the  form  of  a 
"technical  file"  this  file  contains  two  types  of  information  : 

* Global  information  about  the  description  which  cannot  be 
specified  m iOl’l 

• Interface  information  to  he  passed  to  the  module  data  base 
for  selection  of  'pectfic  IC*s  (his  information  describes  the 
desired  logical  and  electric ai  characteristics  of  the  inputs 
and  outputs  of  the  device  being  allocated. 

A small  portion  of  the  ISPL  description  of  an  elevator  controller 
is  shown  in  fig  1,  along  with  relewanl  portions  of  the  compiler 
symbol  fable  and  statement  table  This  description  will  be  used  as 
a running  example  in  describing  the  allocator.  The  technical  file 


for  the  controller  is  shown  m fig.  2.  The  PPOCCSS  specification 
indicates  that  there  are  two  separate  asynchronous  control 
environments  present  in  the  complete  controller  description.  The 
input  and  output  lines  and  their  characteristics  are  specified 
under  the  headings  INPUT  and  OUTPUT 


IV  Allocator  Data  Structures 

As  shown  m table  I,  the  allocator  builds  seven  major  data 
structures  during  the  allocation  of  an  ISPL  description  The  first 
three,  along  with  the  compiler  symbol  table,  comprise  fhe  portion 
of  Ihe  data  structures  which  function  as  symbol  tables  for  the 
allocator  The  path  graph  (fig.  3)  contains  the  allocated  data  part 
of  the  cievice  and  is  Ihe  primary  output  from  the  allocator.  The 
palh  table  and  palh  parallelism  table  are  the  major  working  data 
structures  Although  the  internal  details  of  these  structures  are 
not  important,  certain  overall  characteristics  should  be  discussed. 


! technical  file  for  e'evator  control 

PR0CCG5  : MAIN  , LOOK. FOR. CALLS  ; 

INPUT  • 

1 input**'  f nr  I nnK.rnn.CAi  I 0 

ui  . ca l I » 1 eve  I down  / e I ec  1 1 1 , 
riot  in.  ra  I I **  level  dnun  / "Ipc  ttl  , 
button  * I eve*  I doun  / elec  Itl  ; 

fig  2 Technical  File  lor  LOOK  FOP. CALLS 


Data  Structures 

1)  Process  Tabic:  One  entry  per  process,  records  variables  and 

defined  procedures  used  by  each  process 

2)  Called  Procedure  T,«hlc:  one  entry  per  defined 

procedure,  records  procedure  usage 
infor  mabon 


3)  Allocator  Symbol  Table:  one  entry  per  allocated  ''artable 

(includes  mpuls  and  outputs)  Contains 
physical  characteristics  of  the  variable 

0)  Operator  Table:  perform*,  symbol  table  function  for  all 
allocated  operators 

b)  Palh  Graph:  graph  representation  of  the  data  part. 

Contains  all  allocated  variables,  operators, 
and  links 

6)  Path  Table:  per  process  record  of  paths  used  by  Ihe 

ISPL  description 

7)  Palh  Parallelism  Table:  per  process  record  of 

parallelism  described  in  the  ISPL  description 


8)  Compiler  Symbol  Table: 

9)  RTM  Statement  Table: 


inputs  from  ISPL  compiler 


Table  1 
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INOEX  LABEL  FLAG  OPCODE  DEST  S3LRCE1  SXRCE2  rERGE  PATHS 


( Declaration*  for  S i mo  I *.  e I eva  tor . con  tro  I ! 

car . f I oor <2: 0>  j 'floor  car  i*  on 

car . cal  I 11S: 0) <>  : 'S  floor*.  1 bit  eacn  u/d 

macro  too. floor  ;•  71 


( Declaration*  for  Look.,  for . cal  I a ' 

•scan  input*  fro*  8 floor* 

! input  used  with  scan 
! input  used  with  scan 
'input  used  with  scan 

! end  declaration*  for  Look. for . call  a ! 

Look. for .call*  : • ( 

Ifloorscan  controls  multiplexors  uhose  Input* 

'are  the  call  out  ton*.  The  outputs  of  the  multiplexors 
fare  upcail,  downcall,  and  button 

scan. f I oor  - 0 next 
Next. f I oor  : • ( 

(uocall  at  scanned  floor  ? 

(IF  uD.call  •»  car . cal  I floscan.  f loor)  1)  n*xt 
'down  call  at  scanned  floor  ? 

IIP  doun.call  •>  car.  cal  I (Boscan.  f loor)  •*  1)  next 
(button  in  car  pushed  for  floor  ? 

(IF  button  •>  ( 

'decide  wether  up  or  down  call 
9ECQ0E  car. floor  GTR  scan. floor  •> 
car. cal  I (lescan. f loorl  » 1; 
car. cal  I !3®*can. f loorl  - 1 
) ) next 

scan. floor  » scan. floor  ♦ 1 next 

(IF  scan. floor  LEO  top. floor  -»  next. f loorl) 

(leave  if  all  floors  scanned;  otherwise  look  at  next  floor 
next  I ook. f or . ca I I > 

)i 


Fig. 1(a)  iSPL  Source  Code  for  LOOK. FOR. CALLS 


scan. f loor<2:0>  ; 
up. cal  I <>  ; 
down. cal  I <>  i 
bu t ton<  > i 


s 

0 

' CLEAR  ’ 'SCAN.F* 

( 33) 

6 

* NEXT. F’ 

< 30) 

1 

•SnERCE* 

7 

e 

1 ISP  • 

10 

8 

’IF  ’ * UP . CAL ' 

( 37) 

11 

0 

' CCNC  ’’XTRAAC’  1’ SCAN.F* 

( S2)  ( 42)  ( 33) 

12 

0 

’WRITE  ' ’CAR.CA’ ’XTRAAC’  1 

( S>  t S2) l 42) 

13 

8 

’SnERCE* 

14 

0 

•IF  ' ‘OOUN.C* 

( IS) 

IS 

0 

* CONC  ’’XTRAAC*  0’ SCAN. F* 

( 52) ( 41) ( 33) 

16 

a 

•URI TE  ’ ’CAR.CA’ 'XTRAAC’  t 

l 5) t 52) 1 42) 

17 

0 

"SJ1ERGE’ 

20 

0 

’IF  ’ ‘BUTTON’ 

( 3) 

21 

0 

'GTR  ’ ’XTFAAA’ ‘CAR.FL’ ’SCAN.F’ 

( 47) ( 6) ( 33) 

22 

0 

’BRANCH’  ’XTFAAA’ 

l 47) 

23 

0 

’CONC  ” XTRAAC’  1 ’SCAN.F’ 

( 52) ( 42) ( 33) 

24 

0 

’WRITE  * ’CAR.CA ’ ’XTRAAC’  1 

< 5) ( 52) ( 42) 

2S 

0 

’JOIN  ’ 

26 

a 

’CONC  1 ’XTRAAC’  0* SCAN.F* 

1 52)1  41) ( 33) 

27 

a 

•WRITE  ’ 'CAR.CA' ‘XTRAAC*  1 

( 5) ( 52) ( 42) 

30 

a 

’SttERCE’ 

31 

0 

•SnERCE’ 

32 

a 

•INCH  ’ ’SCAN.F' ’SCAN.F’ 

( 33!  ( 33) 

33 

a 

’LED  ” XTFAAA' ’SCAN.F'  7 

( 47) ( 33) ( 44) 

34 

0 

’IF  ’ •XTFAAA’ 

( 47) 

3S 

4 

’JOIN  ’ •NEXT.F’ 

( 38) 

36 

0 

’SnERCE’ 

37 

0 

•NOOP  ’ ’NEXT.F’ 

( 30) 

Fig.l (c) 

ISPL 

Compiler  Statement  Table  for  LOOK.! 

4 

13  13.11 


17  17. IS 


31  31.21 


30  23. 2S 


36  36. 3S 
6 

6 


CALLS 


INOEX 

TYPE 

FLAGS 

0EF 

BLK 

L8L 

BCNT 

3 

2 

10000000 

0 

0 

0 

1 

S 

1 

10000000 

8 

a 

0 

l 

6 

2 

10000008 

0 

0 

0 

3 

IS 

2 

10000000 

0 

0 

0 

1 

22 

4 

10001100 

0 

9 

3 

0 

30 

4 

10000100 

0 

8 

6 

0 

33 

2 

10000000 

0 

0 

0 

3 

37 

2 

10000000 

0 

a 

0 

1 

41 

3 

10000001 

a 

ft 

a 

1 

42 

3 

10000001 

a 

a 

a 

1 

44 

3 

10000001 

a 

0 

0 

3 

47 

10 

10000001 

a 

0 

0 

l 

52 

7 

10000001 

0 

0 

a 

4 

UCNT  PNAflE  UOROS:  0 1 TS:NArE  (POSITION) 
1 •BUTTON’ 

28  * CAR . CA*  (0(17) t 17 (81 1 
1 ’CAR.FL’ *0(2) : 2 (0) > 
l * DOWN . C ' 

0 ’LOOK.F’ 

0 *N£XT.F’ 

1 ’SCAN.F'  <0 (2) 1 2 (0)  > 

1 ’UP. CAL’ 

0 0 
0 1 

a 7 

0 'ITFAAA* 

0 ’XTRAAC’ 


Fig. 1(b)  ISPL  Compiler  Symbol  Table  for  LOOK. FOR. CALLS 
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LINK  0 I LINK  0 ) LINK 


[ 0..0  TPQ 

LINK  0 | 

’ 1.1  TP| 


MUX  2 X <l>  +-\StUCT 

C$D 

J 

io.O  tPO 


0.0  IPO 

LINK 

r _^J 

i 

| o.o  TM 

L 

;p-3  TPQ 
| LINK  Oj 

o.3  ;pi 


CARCALL[I5  0J'> 


q. 

C2^LJ 

jO.3  TPO 

0.0  IPt 

■ IM*  PrOC 

. .... 

proc 

LINK 

mdo 

0.3  »P 

1 

fo.0  tPO 

FIG.  3(a)  PATH  GRAPH  FGR  LOOK.FOR.CALLS 

L ‘N  ^ umtructurto 

[ -------  »vi«bla  end  «trw<*gr« 


VARIABLE 

NODE 


;0.3  TPO 
I LINK  0 
I *.y  Ip 


MUX  2 x < 4>  H^mcn 


. wn*tru«lwr*d  »ul*ul  drawf* 
opul  bit  idmilim 

•*  <l*M  bil>.«ritM  batik 
•to  bit  «<  * v*«.*at*  •*  b<l  0 


- •ulpwl  KMtlllM  (lay 
. »ul*ul  b«l  €•■«•«  )>•«• 


jO-I  'PO 

LINK  o"l 

■ I 

/ 0.2  IP1 


j0.3  TPO 

| LINK  0 

/ 0..2  tP| 


[ 0.0  TPO 

LINK 

°1 

0.0  tPl 

Cp 

OOWN.CALL<> 


| 0.0  TPQ 
I HUNK  0 I 


1 0.0  TPO 

i ^link  n 


j 0..0  TPO 

[hunk o| 


| UP  CALLo 


l 0 ,0  TPO 

I HUNK  ol 


! 0.0  TPQ 

[hunk  0 ( 


FIG.  3(b)  PATH  GRAPH  FOR  LOOK.FOR.CALLS 


CONCATENATION 

NODE 


— -*?» tffliAV2S!X,'llb  <*~*«..~  «*•».«  w«.  WALf  link 

lJ 


1.3  CPO 

I HUNK  \\ 


u**d  <•  iNdly  on*  *f  • c*nn*<ti*n 

U*  lot**  go*  by  I to  <•*<••)  *n*c»l*o 
(•«••  •>•  d*ni«M  t* 


OPERATOR 

NODE 


Yj<-  - - - -*•*»*•«»  «*wt*  ( aty  to  any  ng«to«  ) 
«•  -----  - b.*»dtb 


- *wt*ul  bklwrfl* 

- ««t«wl  ( mmy  *(««  to  **y  *v«tor> 


C0NNCCTI0M  FLAG  COOC 


^ IN  ^ < - - --  --  --  - u««l»u<lu*»d  >n*g|  •*'!• 

' / •gH-*'*o/(»*->wtliyl*.  d*<*  p*IK  « to«** 

MULTIPLEXOR/  ^ 1 

DEMULTIPLEXOR  MUX  2X  '8>  L-rSflCCf)  «...  p*ih  •*«*««  (*mr*4  .«•«< 
NOOE  * N I 


. »•••  path  b.t.mifc 
gn«<'V<<Uk*d  tu'oul 


CONSTANT 

*tOOE 


r -n*ltnl  ilivilw* 

output  *tv*>(* 


FIG  3(c)  0ASIC  PATH  GRAPH  GROUPS 


FIG  3(b)  BASIC  PATH  GRAPH  GROUPS 
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Duo  to  the  diversity  and  quantity  of  information  required  by 
the  allocator,  and  the  need  to  access  this  information  in  a variety 
of  orderings  with  a variety  of  Keys,  the  data  structures  are 
heavily  cross  referenced  and  contain  varying  amounts  of 
redundant  information.  In  particular,  it  may  seem  that  the  path 
table  and  path  graph  are  highly  redundant.  However,  the  graph 
structure  of  Hie  path  graph  makes  path  location  in  the  graph  a 
combmator ial  problem  The  path  table  provides  an  alternative 
organization  which  reduces  the  location  of  a oath  to  a linear 
search  and  facilitates  optimization  by  Keying  on  the  operation 
and  its  sources.  In  general,  the  diversity  of  structures  enables 
the  allocator  to  efficiently  locate  information  and  relate  it  to  both 
the  original  ISPl  description  and  the  allocated  data  part. 

A rough  measure  of  the  complexity  of  the  data  structures  can 
be  obtained  in  terms  of  the  example  ISPL  description.  The 
process  LOOK  FOP  CALLS  contains  16  RTM  operations  in  the 
compiled  ISPL  code  requiring  path  allocation,  and  6 variables. 
Although  the  complexity  varies  due  to  the  dynamic  creation  and 
deletion  of  some  structures  and  is  also  highly  dependent  on  the 
degree  of  paralclism  and  the  number  of  repetive  operations 
present  in  the  description,  approximately  55  words  of  storage 
are  used  per  line  of  ISPL  PTM  code,  and  *35  words  of  storage  per 
variable. 


V Allocator  Algorithms 

The  allocator  begins  by  examining  the  variables  and  logical 
mappings  declared  by  the  user  to  see  if  they  can  be  implemented 
in  hardware.  A complete  description  of  the  ednstramts  imposed 
on  mapp.ngs,  and  the  implementation  of  array  mapping  access 
structures  is  included  in  appendix  A.  If  no  constraint  violations 
are  detected,  the  allocator  proceeds  to  break  the  ISPL 
description  into  processes  and  construe!  the  three  additional 
symbol  tables  used  in  the  allocation.  The  importance  of  this 
breakdown  is  derived  from  the  fact  that  each  process  represents 
a separate  asynchronous  control  environment.  If  there  are  no 
shared  resources,  this  presents  no  problem,  as  each  process  can 
he  treated  in  essence  as  a separate  device  description  and 
allocated  independently.  The  existence  of  shared  variables  or 
procedures,  however,  introduces  several  problems.  In  the  case  of 
procedures,  the  allocator  is  capable  of  two  actions.  It  can  absorb 
t He  procedure  into  each  process  by  creating  a separate 
hardware  incarnation  of  the  procedure  internal  to  each  process, 
or  it  can  treat  the  procedure  as  if  it  were  itself  a separate 
process  and  allocate  an  independent  hardware  incarnation.  For 
the  second  action,  a<cn'.«.  to  the  procedure  would  then  be 
controlled  by  an  arbitration  structure  subsequently  created  by 
the  control  allocator.  In  the  case  of  variables,  the  access 
arbitration  structure  would  again  be  created  by  the  control 
allocator.  However,  within  the  control  context  of  a given  process, 
fhc  variable  mind  be  regarded  as  subject  to  random  change  due 
to  accesses  by  oilier  processes.  This  will  have  a strong  influence 
on  temporary  storage  allocation. 

Upon  completing  the  process  breakdown,  the  allocator 
initializes  Hie  path  graph  by  performing  the  allocation  of  the  base 
variable  storage  elements.  S<ncc  ISPL  does  not  require  explicit 
memory  address  or  data  registers,  these  are  also  assigned  and 
allocated.  If  these  registers  have  indeed  been  explicitly  specified 
in  the  ISPl,  this  can  he  readily  ascertained  at  the  end  of  the 
allocation  and  the  allocator  MAR  and  MDR  deleted.  After  the  basic 
storage  elements  have  been  allocated,  the  hardware  necessary  to 
implement  any  array  mappings  is  allocated  (again,  see  appendix 
A).  Pass  one  processing  is  completed  by  the  creation  of 
standardized  access  pointers  for  each  enlry  in  the  compiler 
symbol  table  indicating  where  and  how  the  entry  may  be 
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accessed  in  the  path  graph.  This  relates  variables  in  the  ISPL 
RTM  code  to  the  allocated  storage  locations  in  the  logical  design. 

The  allocator  now  begins  pass  two  processing.  This  is 
performed  by  process,  with  hardware  allocahon  and  optional 
optimization  (in  future  versions)  performed  independently  for 
each  process  The  allocator  obtains  the  starting  point  of  a 
process  in  tfie  RTM  statement  table  and  performs  a statement  by 
statement  allocation  of  the  links,  operators,  and  (if  necessary) 
temporary  storage  needed  to  implement  the  operation.  Allocation 
of  an  RTM  statement  begins  with  an  examination  of  the  access 
pointers  of  the  source  variables.  A check  .s  made  for  array 
memory  accessing  conflicts  if  both  sources  are  stored  in  array 
storage  and,  if  needed,  a temporary  is  allocated  to  hold  one 
source  while  the  other  is  accessed.  After  the  necessary 
operations  to  make  the  sources  accessible  have  been  determined 
and  any  required  links  and  storage  have  been  entered  in  the 
path  graph,  the  palti  table  is  accessed  to  determine  if  the  path 
has  been  previously  allocated.  If  it  has,  it  is  reused,  and  the 
asociatcd  operator  is  expanded  in  size  if  net'ssary.  If  the  path 
has  not  been  allocated,  the  necessary  links  and  operator  are 
entered  in  the  path  graph  and  the  path  is  recorded  in  the  path 
table.  An  analysis  is  now  made  to  determine  the  appropriate 
destination,  based  on  the  destination  specified  by  the  statement 
table  entry  and  the  characteristics  of  the  operation  sources. 
Temporary  destinations  generated  by  the  ISPL  compiler  are 
removed  at  this  point  and,  depending  on  the  stability  of  t tie 
operation  sources,  the  operation  result  is  either  left  at  the 
operator  output  for  direct  cascading  to  the  next  path  (as  in  a 
combinatorial  logic  network),  or  gated  to  an  allocator  generated 
tempor  ary. 

Temporaries  generated  by  the  ISPL  compiler  are  useless  to 
the  allocator  due  to  a generation  and  usage  criterion  which, 
though  adequate  for  simulation,  is  unsuitable  *or  hardware 
implementation  The  allocator  generates  temporaries  when  either 
source  could  change  before  the  operation  result  is  used  Cases 
where  this  might  occur  are  : 

t Either  source  is  shared  between  two  or  more  processes 
and  thus  is  subject  to  random  change. 

* Either  source  is  an  array  memory  access.  This  is  necessary 
ctue  to  the  fact  that  it  is  imoossible  in  the  general  case  to 
know  if  the  value  in  the  MOR  will  change  without  extensive 
processing  A worst  case  can  plausibly  be  developed  here 
which  requires  n statement  look-ahead,  a value  trace  of 
the  MAR.  and  is  still  undccidabie  without  violating  the 
definition  of  the  ISPL  parallel  action  construct. 

t Either  source  is  a temporary  storage  location  allocated  in  a 
previous  instruction.  The  justification  for  this  condition  is  a 
complex  combination  ol  problems  ’n  the  ISPL  language  and 
problems  internal  to  the  allocator,  relating  again  mainly  to 
problems  m determining  the  stability  of  the  temporary 
over  parallel  operations. 

When  the  destination  has  been  chosen,  the  necessary  link  is 
created  in  the  path  graph  and  any  further  operations  necessary 
to  store  the  destination  m array  storage  are  determined  and 
performed  if  they  arc  required. 

Several  special  cases  are  worth  mentioning  Subfield  accesses 
of  variables  and  logical  negation,  winch  are  operations  in  the 
ISPL  RTM  code,  do  not  require  t lie  full  processing  just  described, 
blit  are  handled  by  manipulation  of  ihe  access  pointers.  The  ISPL 
control  operations  using  data  vaiues  as  conditionals  require  only 
the  source  processing,  so  that  a pointer  can  be  constructed  to 
allow  the  control  allocator  to  access  the  data  value.  Finally, 
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Opor  at  ion-.  commonly  available  as  register  functions 
(me  /dec  ,i  tear, slid  Is)  are  recognized  and  the  required  function  is 
added  lo  ll»p  register  characteristics. 

After  each  statement  is  processed,  the  path  created  is 
chocked  against  all  other  paths  in  use  concurrently.  Parallel 
operations  arc  recorded  in  the  path  parallelism  table,  and  Hie 
user  is  warned  of  any  array  memory  or  register  access  conflicts 
or  ambiguities  that  might  occur.  No  more  than  a warning  can  be 
generated,  however,  as  t ho  allocator  cannot  detect 
synchronisation  mechanisms  * pecificd  by  the  user  in  the  ISPL 
description  which  could  resolve  the  ambiguity  or  conflict. 

After  a process  has  been  allocated  as  described  above,  the 
path  graph  contains  a worst  case  allocation  of  the  process  in 
terms  of  operators  and  temporary  registers.  Optimization  can  be 
performed  here  using  the  parallelism  information  and  path 
allocation  records  formed  during  the  allocation  of  the  process.  As 
an  example  optimization,  compression  of  temporary  registers  is 
performed  using  the  criterion  "combine  the  registers  if  they  are 
compatible  m size  and  no  parallel  or  sequential  usage  conflicts 
exist".  After  the  optimization  routines,  the  path  parallelism  table 
is  cleared  and  the  path  table  selectively  purged  so  that  these 
structures  do  not  become  unmanageably  large. 

After  all  processes  have  been  allocated,  multiplexers  are 
allocated  where  needed  and  the  allocation  is  complete. 


VI  Allocator  Outputs 

The  primary  output  of  the  allocator  is  the  path  graph,  winch 
is  used  by  the  data  base  module  m conjunction  with  the  allocator 
symbol  table  to  map  IC’s  onto  the  logical  allocation.  The  allocator 
also  produces  a dump  of  the  mapr  internal  tables  for  the  user. 


VII  Allocator  Performance 

The  allocator  described  here  is  currently  undergoing  testing, 
so  the  results  presented  here  arc  preliminary.  Also,  the  actual 
hardware  is  to  be  allocated  by  the  module  data  base,  which  is 
currently  in  the  design  stage.  Ihwovc',  by  performing  a hand 
allocation  of  IC  chips  onto  the  path  graph,  we  have  obtained 
preliminary  results  The  l$Pt.  description  used  was  part  of  the 
design  style  experiment  described  in  [Tho  •'as  77],  which 
provides  a controlled  measure  of  how  welt  Hie  aliucafor  performs 
in  relationship  to  human  designers.  The  results  are  shown  in 
table  ? the  cost  figures  for  the  allocator  des-gn  were  derived 
using  Thomas'  cost  estimate  : 


Cost  for  data  part  of  process  LOOK. FOR  CALLS  as  implemented  for 
Thomas’  design  experiment: 

Designer  10:  $32.49  Designer  5:  $71.45 

Cost  for  clata  pari  of  process  LOOK. FOR  CALLS  as  implemented 
from  allocator  path  graph*: 

$47.63 

• The  same  subset  of  the  TTL  chip  family  used  in  the  design 
experiment  was  used  to  implement  the  allocator  path  graph. 

Table  2 


Cost  - (total  chip  cost)  ♦ ($3  overhead/chip) 

One  can  see  that  the  cost  of  the  automated  design  falls  within 
t lie  same  order  of  magnitude  as  t tie  cost  of  designs  produced  for 
the  design  experiment,  with  no  significant  optimization  on  the 
part  of  the  allocator. 


VIII  Conclusions  and  Future  Research 

The  encouraging  results  described  here  have  led  us  to  the 
following  conclusions  : 

• the  basic  experimental  allocalor  described  here  will  function 
successfully  as  the  base  for  an  expanded  allocator  with 
optimization  capabilities 

• specific  module  set  information  is  not  neeoed  to  produce  a 
non-optimal  allocation 

• the  size  of  the  ISPL  descriplton  which  can  be  handled 
depends  only  on  the  amount  of  core  available  to  the 
allocator 

• ttie  allocator  can  detect  user  constructs  in  the  ISPL 
description  which  will  proauce  complex  hardware  or 
unreliable  operation 

In  addition,  we  have  concluded  that  a large  portion  of  the 
complexity  of  the  allocalor  is  due  to  : 

• The  ability  lo  allocate  multi-process  ISPL  descriptions. 

• The  lack  of  a one-to-one  correspondence  between  the 
compiled  RTM  statement  table  operations  and  the  actions 
necessary  lo  perform  these  operations  in  a hardware 
implementation. 

« The  availability  of  t lie  logical  mapping  facility  m ISPL. 

Future  results  will  include  a more  extensive  evaluation  of  the 
allocator  performance  using  Thomas*  design  style  experiment  as  a 
yardstick,  and  comparison  with  other  'arge,  multi-process  designs 
currently  under  construction  at  C-MU. 


Appendix  A Mappings 

The  ISPL  language  contains  a generalized  logical  mapping 
facility  allowing  the  user  to  declare  a logical  variable  in  terms  of 
a previously  declared  physical  or  logical  variable.  The  only 
restriction  imposed  by  the  ISPL  compiler  is  that  the  physical  size 
(total  bits)  of  each  side  of  the  declaration  be  equal  For  mappings 
where  the  mapped  variable  is  declared  as  a register  type 
variable,  tins  restriction  is  sufficient.  When  the  mapped  variable 
is  declared  as  an  array  structure,  however,  additional  restrictions 
must  be  imposed  to  insure  that  a reasonable  hardware 
implementation  of  Hie  mapping  can  be  created.  Consider  the 
following  example  mapping,  winch  a/ ill  be  used  to  define  the 
terms  used  in  the  equation  which  defines  the  mapping 
constraints.  The  first  declaration  is  the  physical  (base) 
declaration,  and  the  second  is  t lie  mapping  declaration. 


A I [0: 1 ,8:9,1  4: 1 5]<0;7>  ; 

AA?[b,9,l2]'0:15>  A I (0: 1 ,8.9,1 4: 15]<0:7>  j 

Define  the  following  terms: 


, 


in 
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main  declaration  declaration  of  A1 

mapping  primary  left  half  of  mapping  declaration 

(AA2) 

mapping  secondary  right  half  of  mapping  declaration 
f A 1 ) (may  in  general  be  all  of  the 
mam  declaration  or  a subset  of 
the  addressing  space  defined  by 
the  main  declaration) 

bifentp  bit  size  of  primary  word  (16  bits 

in  this  example) 

bitcntr  ::=*  bit  size  of  secondary  word  (8  bits 

in  this  example) 

d *.:■  Ig2(bitcntp/bitcnt$)  (1  in  this 

example) 


With  these  definitions,  any  mapping  satisfying  the  equation 

(«*dr p ♦ X)Td  - adr$  where  X » (bOsT(-d))  - bOp  - 
constant  and  T is  the  logical  shift 
operation  (left  shift  is  positive 
direction) 

can  be  implemented  with  at  most  an  addition  and  wired  shift  in 
the  address  path,  a multiplexor  /demultiplexor  pair  to  provide  the 
necessary  gating  into  and  out  of  the  MDR  of  the  main  definition 
variable,  and,  for  the  case  where  bitcntp  > bitcnt$,  a MOR  for  the 
primary  declaration  to  assemble  the  primary  word  while  the 
necessary  number  of  memory  accesses  are  made  in  the  main 
memory. 

The  path  graph  representation  of  the  example  mapping  as 
allocated  by  the  data  memory  allocator  is  attached  as  fig.  A-l. 
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APPENDIX  IV 

The  PDP-8  Design 

This  section  contians  the  PDP-8  ISPL  description,  a block  diagram 
of  the  allocator  output  and  the  Chip  Count  for  the  DEC  and  automated 
CMU  PDP-8.  THE  CMU  DESIGN  IS  PRELIMINARY  - IT  HAS  NOT  BEEN 
VERIFIED  AND  THE  CHIP  COUNT  IS  APPROXIMATE. 

I 
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PDP8  :« (dec  I are 

! The  basic  PDP-8  instruction  set,  not  including  the  extended  arithmetic 
! element  (EAE)  option.  I/O  instructions  are  limited  to  those  dealing 
! with  the  interrupt  mechanism 

!>v*  Memory. State  VoV 

MXMemory  [0:4095] <0: 11>; 

! t'ti’e  Processor. State  ** 

I ac<0: 1 2> ; 

LXLinko  :»  lac<0>! 

ACXAccumu I ator<0: 11>  :«  lac<l:12>; 

PCXProgr am. Counter <0: 1 1 > ; 

RUNo; 

I . STATEo ; 

I.REQUESTo; 

SUI TCHES<0: 1 1 > ; 

IrtiV  I ns  true  t i on.  Format  ** 

i \ i ns  true t i on<0: 11>; 


opXoperat i on. code<0s  2> 

:=  i<0:2>; 

ibXindirect.bi  to 

:=  i <3> ; 

pbXpage.  0.  b i to 

•»  I <4>; 

paXpage. address<0:6> 

i <5 : 1 1 > ; 

IO.SELECT<0:5> 

:■  i <3 : 8> j ! device  select 

i o. contro 1 <0: 2> 

i <9: 1 1 > ; ! device  operation 

lO.Plo 

:»  i o. contro 1 <0>; 

iO.P2<> 

s-  io.control<l>| 

IO.PAo 

:■  io.control<2>; 

smao  i<5>? 

! skip  on  minus  AC 

spao 

=■  i<5>; 

! skip  on  posi tive  AC 

szao 

■ i <6> ; 

! skip  on  zero  AC 

snao 

= i <B> ; 

! skip  on  AC  not  zero 

snlo  i <7> ; 

! skip  on  L not  zero 

sz  1 <> 

» i <7  > ; 

! skip  on  L zero 

i so 

- i<8>; 

! invert  skip  sense 

groupo 

= i <3>j 

! microinstruction  group 

c 1 a<> 

- i<4>; 

! clear  AC 

c 1 1 <> 

- i<5>; 

! clear  L 

cmao 

« i<G>; 

! complement  AC 

cm  1 <> 

= i <7  > j 

! complement  L 

raro 

- i<8>: 

! rotate  right 

ra  1 <> 

- i<9>s 

! rotate  left 

r to  i <1 0>; 

! rotate  twice 

iaco  i < 1 1 > i 

! increment  AC 

osr  <> 

- i<9>? 

! logical  or  AC  uith  SWITCHES 

h 1 to 

■ i < 1 0 > * 

! hal t the  processor 
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(I. STATE  *-0)) 


); 


skip. group  :»( 

skip  «-  0 Next 
(Decode  is  -> 

((If  sal  And  (L  Eql  1)  »>  skip  «-  1); 

(If  sza  And  (AC  Eql  0)  *■>  skip  «-  1); 

(If  sma  And  (AC  Lss  0)  ->  skip  «-  1)); 

((  I F ( szl  and  sna  and  spa)  Eql  0 «>  skip  «-  1); 
( If  szl  And  (L  Eql  0)  ■>  skip  «-  1); 

(If  sna  And  (AC  Neq  0)  ->  skip  «-  1); 

(If  spa  And  (AC  Geq  0)  ■>  skip  «-  1))  ) 

Next 


80 


(If  c I a ■>  AC  «-  0)  Next 

(If  oa r ->  AC  AC  Or  SUITCHES)); 

(I  f cla  ->  AC  «-  8)  ! eae  group 

) 

) 

) ; 

execute  :»( 

EFADD  NEXT 

(Decode  op  »> 

AC  «-  AC  And  N leadd)  • 

I ac  «-  I ac  + N Ceaddl ; 

( 

(Ueaddl  «-  11  leadd]  + 1 Next 

(If  flCeaddl  Eql  0 =>  PC  «-  PC  + 1) ) ; 

( 

flteaddl  «-  AC  Next 
AC  - 0) ; 

(fl  (eaddl  «-  PC  Next 
PC  - EADO  + 1); 

PC  ♦-  eadd; 
input. output; 

operate 

) ) 


era  I ced 

! frit  I netruct i on. I nterpretat i on  ** 
start  :-( 

i *-  M [PC] ; last. pc  <-  PC  Next 
PC  <-  PC  + 1 Next 
execute  Next 

(If  I. STATE  And  I. REQUEST  -> 
( H [03  - PC  Next 

pc  - in 
) 

NEXT  START 
) 
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DEC  - PDP-8/E  Chip  Count 

The  following  chip  count  was  taken  from  M8300  "major  registers." 

/ti  \ 


Part  It 

l^TTL  equiv. 

/ Quantity 

Function 

7400 

3 

Quad  2 input  NAND 

7402 

1 

Quad  2 input  NOR 

74H04 

2 

Hex  inverter 

7420 

1 

Dual  4 input  NAND 

7430 

1 

8 input  NAND 

74H87 

3 

4 bit  true/complement 

7483 

3 

4 bit  binary  full  adders 

84151 

12 

1 of  8 MUX 

74153 

6 

dual  4 to  1 MUX 

8271 

74194 

15 

4 bit  universal  shift  reg. 

8266 

74157 

8 

Quad  2 to  1 MUX 

8235 

74H87 

3 

4 bit  true/ complement 

8881 

7401 

6 

Quad  2 input  NAND 

Total  64 

integrated  circuit  chips 

{ 


82 


CMU  - PDP-8  Chip  Count 


The  following  chip  count  was  taken  from  the  part  of  the  automated 
design  corresponding  to  the  DEC  PDP-8  M8300  "major  resistors."  The  chips 
we  allocated  by  hand  using  a "worst  case"  allocation.  For  example,  if 
the  allocator  specified  a 7 to  1 13  bit  MUX,  one  was  provided,  even  if 
the  MUX  could  be  decomposed  into  a simpler  structure. 


Part  of  Path  Graph 

Part  # 

(TI  TTL  Equiv.) 

Quantity  Implemented 

74151 

13 

MUX  7 x <13> 

8271 

74194 

3 

AC<0: 11> 

7474  (h) 

1 

L<0>,  TREG3  <0> 

7402 

3 ; 

j-  0R<  12> 

7404 

2] 

74153 

7 

MUX  3 x <13> 

8271 

74194 

3 

TREG3  <1:12> 

8271 

74194 

3 

LAST.P<0: 11> 

7483 

3 

7400 

3 

7404 

3 

1 INCR<13> 

7420 

1 

| EQL<12> 

7430 

1 

7483 

4 

ADD<14> 

7400 

3 1 

| 

7404 

2 ! 

> AND<12> 

74153 

6 

MUX  4 x <12> 

8271 

74194 

3 

TREG1  <0 : 1 1> 

74153 

6 

MUX  3 x <12> 

8271 

74194 

3 

PC<0:11> 

74153 

6 

MUX  3 x <12> 

8271 

74194 

3 

TREG2  <0:11> 

7483 

3 

INCR<13> 

8271 

74194 

3 

EADD<0: 11> 

74153 

6 

MUX  3 x <12> 

94  integrated  circuit  chips 


Total 


CMU  PDP-8  Design 


The  nexC  4 pages  contain  the  automated  PDP-8  design. 

All  connections  contain  the  number  and  position  of  bits  specified. 

Output  wires  not  attached  are  used  by  the  control  to  test  for  certain 
conditions. 

Some  :rjX  connections  not  specif ied(and  operator  input  connections) 
are  padded  with  zeros;  a few  are  padded  with  ones  or  not  used.  Details 
are  found  in  the  actual  allocator  output  files. 
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